10 Jahre Java: vom Sandkasten zum Tiger

Es gibt im Jahre 2005 gleich mehrere Jubiläen zu feiern. In diesem Beitrag wollen wir 10 Jahre Java beleuchten und kommentieren. Wir schlagen dabei eine Brücke zum Firmenjubiläum der ORDIX AG, die in ihren 15 Jahren auch ein gutes Stück Weg mit Java zurückgelegt hat.

Ab 1990 - Embryonalentwicklung

Betrachtet man die Java-Geschichte, kommt man an den Bemühungen von Sun Microsystems Anfang der 90er Jahre nicht vorbei. Dort wurde in internen Untersuchungen und geheimen Projekten nach neuen technologischen Möglichkeiten gesucht, um zukünftig sogenannte "intelligente Geräte" steuern zu können. Bei diesen Geräten dachte man an Kühlschränke, Staubsauger, TV Settop Boxen und ähnliches.

Im "Green Projekt" bei Sun arbeiteten u. a. die Vordenker und Visionäre Bill Joy und James Gosling, die aus diesen Bemühungen heraus zunächst mit einer neuen Programmiersprache namens "Oak" aufwarteten. Wegen namens- und lizenzrechtlichen Schwierigkeiten wurde sehr bald daraus der Name "Java".

In dieser Zeit wurde auch eine der wichtigsten Eigenschaften dieser neuen Programmiertechnologie festgelegt: die Plattformunabhängigkeit. Java Programme sollten auf möglichst allen Rechner- und Systemumgebungen laufen, ohne dass jeweils angepasste Versionen erstellt werden müssen, wie das beispielsweise bei C erforderlich ist, obwohl das einen ähnlich übergreifenden Ansatz hatte.

Dafür war es unabdingbar, von dem so beliebten Compiler-Ansatz Abstand zu nehmen und auf die gute, alte Interpreter-Technologie zu setzen.

1995 - Java 1.0, Geburt und Krabbelalter

Im Jahre 1995, genauer im Mai erblickte Java 1.0 das Licht der Welt. Das erste Java Development Kit (JDK) konnte von den Sun Servern heruntergeladen werden und umfasste eine im Vergleich zu heute überschaubare Anzahl von Klassen (Größenordnung ca. 1.000; heute: ca. 12.000).

Großer Hoffnungsträger für Java zu der damaligen Zeit und für die Technologie, der man ein sogenanntes "Killerpotential" zutraute, waren die Java Applets.

Die waren revolutionär und machten zu Beginn auch den größten Unterschied zu den etablierten Programmierumgebungen aus. Denn man konnte mit Applets zum ersten Mal recht elegant Programmfragmente schreiben, die per Internet transportiert werden und an "fremden Plätzen", sprich im Client Browser, ihre Arbeit verrichten.

Robustheit und Sicherheit sind bei Java von Anfang an ganz wichtige Aspekte, nach denen das Design der Sprache entwickelt wurde.

So gab es bereits im ersten Java 1.0 die sogenannte "sand box" (siehe Abbildung 1). Dies ist ein abgeschotteter Sicherheitsbereich auf dem Client, in dessen Grenzen ein Applet wirken darf. Er umfasst z. B. die Bereiche einer Festplatte, die beschreibbar sind, oder die Teile der Systemumgebung (Environment), die ausgelesen werden dürfen.

Nur so konnte gewährleistet werden, dass Applets nicht außer Kontrolle geraten und Sabotage auf dem Client System anrichteten.

Der Nachfolger zu JDK 1.0 stand im Februar 1997 zur Verfügung, hörte auf den Namen JDK 1.1 - Wer hätte das gedacht? - und wartete besonders mit Erweiterungen auf.

Zu den wichtigen Neuerungen zählten der Zugriff auf Datenbanken per JDBC, eine erweiterte Ereignisbehandlung im Abstract Windowing Toolkit (AWT) und die Behandlung von Unicode Zeichensätzen.

1998 - Java 1.2, endlich alleine laufen

Mit der Version Java JDK 1.2 im Jahre 1998, auch Java 2 genannt, wurde der Desktop zur Hauptzielscheibe.

Aus dem eher spröden und nicht sehr umfangreichen AWT zur Oberflächenprogrammierung, das darüber hinaus auch dem Prinzip der Plattformunabhängigkeit entgegen stand, entwickelte sich das sehr viel modernere "Swing", eine komplett überarbeitete GUI Klassen- und Interface-Sammlung, die u. a. mit eigenständigem "Look & Feel" daherkam.

Des Weiteren kam eine große Anzahl von zum Teil sehr mächtigen GUI-Klassen im Swing hinzu, die die Gestaltung von sehr ergonomischen Masken und anspruchsvollen GUI-Applikationen erlaubten.

Abb. 2: Gesamtanzahl aller Klassen und Interfaces  von jeweils einer Java Version. Man sieht deutlich das  geringe Wachstum zwischen 1.2 und 1.3..

Dieser Versionssprung war der bis dahin größte und sollte es auch lange Zeit bleiben. Nicht nur, dass es etliche neue Bibliotheken und APIs gab (siehe dazu auch Abbildung 2), selbst die Aufwärtskompatibilität war zwischen dem JDK 1.1 und JDK 1.2 nicht zu 100 Prozent gegeben. Das lag hauptsächlich an Veränderungen, die an der Sprache vorgenommen wurden.

Diese Stabilität und der geringe Änderungsbedarf an der Grundarchitektur - von dem Sprung 1.1 nach 1.2 mal abgesehen - spricht für das sehr gründliche und konsistente Design, das die Java Architekten schon in den Anfängen der 90er Jahre in diese Technologie gesteckt hatten.

2000 - Java 1.3, "lauf schneller"

5 Jahre gibt es die Plattform Java nun schon und sie hat sich prächtig entwickelt. Für neu zu startende Entwicklungsprojekte kommt man an dieser Technologie nicht mehr vorbei und darüber hinaus gilt es als schick, sich damit zu beschäftigen.

Man hat bei Sun aber lange Zeit die Funktionalität und Mächtigkeit der Application Programming Interface (API) zu sehr in den Vordergrund gestellt und das Thema Geschwindigkeit und Performanz darüber leicht vernachlässigt - womöglich aus Gründen von Kapazitätsengpässen auch vernachlässigen müssen.

Daher waren auch äußerst kritische Stimmen nicht zu überhören, deren Unzufriedenheit sich zwar aus vielerlei Quellen nährte, die aber in einer plakativen, wenig differenzierten Aussage münden: "Java ist langsam".

Dieses Urteil haftet unserem Geburtstagskind seitdem derart hartnäckig an, dass es sich bei vielen Zeitgenossen inzwischen als unerschütterliche Wahrheit festgesetzt hat. Diese sind auch nicht durch noch so gute Performanzverbesserungen oder Laufzeitoptimierung zu beeinflussen und erschweren hin und wieder sachliche Diskussionen zu diesem Thema.

Diesem (Vor-)Urteil ist Sun im Jahre 2000 mit der Version Java 1.3 begegnet.

Für Performanzprobleme sorgte in den früheren Versionen u. a. der sogenannte "Garbage Collector" (GC). Der GC war von Anfang an fester Bestandteil der Java Plattform und war entstanden aus Unzulänglichkeiten, die man bei der Programmiersprache C++ ausgemacht hatte.

C++ stand in vielen Bereichen Pate für Java, so auch bei der Konstruktion von Objekten im Hauptspeicher (Schlüsselwort new). Aber die Freigabe von Objekten, die in C++ mittels delete vom Entwickler zu erledigen ist, haben die Java Architekten dem Entwickler entzogen.

Oder besser: Sie haben den Entwickler davon befreit und überlassen es ausschließlich dem GC.

Dabei handelt es sich allerdings auch um eine sehr ambitionierte Aufgabenstellung: "Finde zu einem bestimmten Zeitpunkt alle Objekte, die nicht mehr referenziert werden und gib deren Hauptspeicher frei."

Betrachten wir folgende Konstellation in einer Anwendung:

Es existieren sehr viele Objekte in einer Applikation und diese weisen eine starke "Verknüpfung" untereinander auf, d. h. viele Objekte halten viele Referenzen (Zeiger) auf andere Objekte.

Da kam bei Java 1.3 die sogenannte "HotSpot" Technologie für den Garbage Collector hinzu, die mit sehr ausgeklügelten Algorithmen und heuristischen Ansätzen für deutlich besseres Laufzeitverhalten sorgt.

Es hat sich nämlich in sehr umfangreichen Untersuchungen bei einer Vielzahl von unterschiedlichen Java-Anwendungen ein interessanter Zusammenhang gezeigt (der allerdings nichts mit dem wirklichen Leben zu tun hat, obwohl sicherlich für einige Internetfrmen, die in dieser Zeit entstanden, ähnliches galt
;-) ): "Die meisten jungen Objekte sterben früh".

Das heißt, dass die Wahrscheinlichkeit, in einer Objektmenge die nicht mehr referenzierten Objekte zu fnden, größer wird, je kürzer die Lebensdauer dieser Menge ist. Dieser Sachverhalt gilt besonders für lokale Variablen, die nur solange existieren, wie sich die Programmausführung im Gültigkeitsbereich befndet, z. B. innerhalb eines Methodenrumpfes.

Mit HotSpot werden Hauptspeicherbereiche nun nach Generationen unterteilt und junge Generationen dabei bervorzugt behandelt. Das bringt bei Applikationen mit sehr vielen lokalen Objekten und Referenzen eine durchgreifende Performanzverbesserung. Auch die Verwendung eines Just In Time (JIT)-Compilers hielt mit der HotSpot Technologie in Java 1.3 Einzug und sorgte ebenfalls für so manchen Geschwindigkeitsrausch.

Im Jahre 2002 kam mit Java 1.4 dann eine Version heraus, die wiederum sehr stark im Umfang zugelegt hatte, nachdem man die Schwierigkeiten mit der Performanz im Griff zu haben glaubte. Zu den markanten Neuerungen gehören u. a. die XML-Verarbeitung, ein "New I/O", die Bildverarbeitung mit "Image I/O", eine völlige Überarbeitung der Security und die Unterstützung von "Assertion". Die Version Java 1.4.2 gilt als sehr stabil und ist in vielen aktuellen Projekten die Programmierbasis, mit der gearbeitet wird.

1997 - 2005, ORDIX setzt auf Java

Eine Beziehung im großen Geflecht und Gestrüpp des Java Universums soll hier natürlich besondere Beachtung fnden. Es ist das Engagement, das die ORDIX AG seit dem Jahre 1997 bis heute mit der Java Technologie verbindet. Das umfasst zahlreiche Entwicklungsprojekte beim Kunden oder auch interne Projekte, die mit dem Einsatz von Java Technik bestritten werden und wurden. In der Anfangsphase waren es häufger Projekte, in denen die Client-Seite in Java realisiert wurde, da gerade ab der Version Java 1.2 die GUI sehr stark in den Fokus geriet.

Die eigentliche Stärke dieser Verbindung Java - ORDIX kommt aber durch eine besondere "Übereinstimmung" zustande. Denn Java hat, was bisher in diesem Artikel nicht thematisiert wurde, schon seit dem Ende der 90er Jahre eine sehr starke Ausbreitung auf den Server erfahren.

Das liegt an grundlegenden Eigenschaften die-ser Technologie wie der Multithreading-Fähigkeit, der umfangreichen Security-Unterstützung, einer sauberen und einfachen Grundarchitektur und vielem mehr. Daher entstand mit der Java 2 Enterprise Edition (J2EE) ein speziell für Serverbelange zusammengeschnürtes Paket, das die "normale" Java Standard Edition (J2SE) beinhaltete und um zahlreiche serverspezifsche APIs und Spezifkationen erweitert wurde.

Und bekanntermaßen hat auch die ORDIX AG besondere Stärken im Serverumfeld, wie nicht zuletzt an den zahlreichen Artikeln in der ORDIX News zu erkennen ist. Diese handeln überwiegend von Serverthemen wie Datenbanken, Netzwerkmanagement, Unix-Administration, Skriptsprachen, Web- und Application Servern und natürlich auch von der Entwicklung mit Java.

Diese Verbundenheit spiegelt sich unter anderem auch im Seminarangebot der ORDIX AG wieder (siehe herausnehmbare Übersicht in der Heftmitte). Hier ist das klassische Thema "Java Programmierung" als Grund- und Aufbaukurs ebenso vertreten, wie die serverseitigen Themen "JSP und Servlet Programmierung", "J2EE für Entscheider" und "EJB Programmierung", um nur einige zu nennen.

Java 5, der Tiger

Enden soll dieser zugegebenermaßen grobe Überblick mit Betrachtungen zu dem neuesten Release aus dem Hause Sun Microsystems, nämlich Java 1.5, oder wie es offziell heißt: "Java 5, Tiger". Mit diesem Release geht Sun auf die Entwickler zu. Das soll heißen, das Motto "Ease of Development" steht als große Überschrift über Java 5 und bildet zugleich dessen große Klammer.

Denn was sich da an Änderungen der Sprache und Erweiterungen der API ergeben hat (lesen Sie dazu auch den dazugehörigen Artikel "Der Tiger ist los" in der ORDIX News 4/2004), kann als umwälzend bezeichnet werden und ist vergleichbar mit dem Wechsel von Version 1.1 zu 1.2 (s. o.) aus dem Jahre 1997.

ORDIX trägt dieser Entwicklung mit einem eigenständigen 3-Tages Seminar Rechnung. "Java 5.0 Neuheiten" ist in dem offziellen Seminarprogramm 2005 hinzugekommen und richtet sich an Java Entwickler, die sich kompakt und umfassend mit den Neuheiten vertraut machen möchten. Das geschieht in bewährter ORDIX Tradition: Mit einem ausgewogenen Verhältnis zwischen Theorie und Praxis.

Dr. Hubert Austermeier (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen