Seite 2: Unterschätzt: die Dokumentation

Inhaltsverzeichnis

Bemerkenswert war unter Java noch die Dokumentation. Zum einen war die Idee so brillant, Quellcode und Dokumentation an einer Stelle zu vereinen. Damit war klar, wo die Dokumentation hinkommt und wie sie idealerweise aufgebaut ist. Die Klassendokumentation beschreibt die Verantwortlichkeiten und den Zweck der ganzen Klasse, und die einzelnen Elemente, Methoden und Felder bekommen zusätzlich ihre eigene detaillierte Beschreibung. Das "zum anderen" ist aber der eigentlich Clou. Aus dieser Dokumentation wurde eine verlinkte Web-fähige Dokumentation erstellt. Diese technische Finesse gebündelt mit der herausragenden Qualität der Dokumentation haben Java zu dem gemacht, was es heute ist.

Zugegebenermaßen mag noch der Umstand geholfen haben, dass Java – was die Sprache betrifft – keine undefinierten Stellen in der Spezifikation hat. Das, was die C- und C++-Programmierer zum Verzweifeln bringt, hat es unter Java nie gegeben. Alles, bis hinunter zum vermeintlich unwichtigsten Bit, ist wohldefiniert; und wer will, kann sogar dafür sorgen, dass auch sämtliche Gleitkommaberechnungen auf unterschiedlichsten Rechnern dasselbe Ergebnis liefern.

Ausgangspunkt für die heutige Konkurrenz

Aber das ist alles schon ein Vierteljahrhundert her, und rund um Java und ihre virtuelle Maschine hat sich viel getan. Neue Programmiersprachen sprießen wie die Pilze aus dem Boden und machen den Eindruck, etwas "besser" zu sein als Java, nicht ganz so altbacken oder altlastig. Diese Programmiersprachen wären aber nichts Wert, wenn ihnen nicht das ganze Java-Universum zur Verfügung stünde. Darüber hinaus belebt Konkurrenz bekanntermaßen das Geschäft. So gibt es kaum noch etwas, was sich nicht auch mit Java umsetzen lässt. Mit den Generics wurde ein großes Problem gelöst, mit den Lambdas und den damit möglich gewordenen Streams ein großes anderes. Module haben sich zwar immer noch nicht so richtig durchgesetzt, aber mit denen wird Java deutlich handlicher und erlaubt es, nur das zu nehmen, was man wirklich braucht. Alles Wünschenswerte, was sonst noch fehlt, ist in Arbeit.

Auch das ist etwas, was Java für sich in Anspruch nehmen kann: früh aus den Erfahrungen und Bedürfnissen der anderen zu lernen und sie an den Entwicklungs- und Entscheidungsprozessen zu beteiligen. Und das noch zu Zeiten, in denen Java selbst weit davon entfernt war, Open Source zu werden. Immerhin konnte man ja auch mit Java Geld verdienen. Denn Java spezifizierte und lieferte die Referenzimplementierung und jeder, der wollte, konnte seine Version liefern, so sie denn den Schnittstellen genügte. Sicherlich ist das eine etwas vereinfachte Sicht der Dinge; im Wesentlichen führte dies aber zu dem unglaublich großen Fundus an Bibliotheken und Frameworks, von denen heute alle Java-Entwickler profitieren.

JVM und Graal

Was man nebenbei bemerkt nicht außer Acht lassen sollte, ist alles das, was sich unter der Haube befindet. Die virtuelle Maschine leistet Unglaubliches. Ohne jede Veränderung kann man immer noch Programme der ersten Version laufen lassen – nur schneller. Das ist wirklich außerordentlich: Bei jeder neuen Version kann man davon ausgehen, dass in den meisten Fällen einfach nur alles schneller geworden ist. Natürlich gibt es immer wieder Ausnahmen, aber diese Unzulänglichkeiten sind dann meist mit der darauf folgenden Version behoben.

Gerne wird dabei vergessen, dass es sich bei Java immer noch um eine interpretierte Sprache handelt. Der Compiler übersetzt zwar die Java-Quellen in Bytecode, aber der wird interpretiert. So wie damals vor 25 Jahren – nur unglaublich viel cleverer und damit viel schneller. Und wegen dieser Art der Interpretation stehen Java zur Laufzeit Informationen zur Verfügung, von denen ein rein statischer Compiler nur träumen kann. Das Allerbeste ist schließlich: Man braucht die Quellen nicht neu übersetzen, um die Features einer neuen Hardware-Architektur nutzen zu können.

Jetzt gibt es noch die neue virtuelle Maschine: Graal. Sie ist in Java geschrieben, was bemerkenswert genug ist, da Java eben doch schnell genug zu sein scheint. Aber diese neue virtuelle Maschine ist deswegen ein Meisterwerk, weil sie sich selbst optimiert. Man stelle sich das Mal vor: Java läuft auf einer virtuellen Maschine, die in Java geschrieben ist. Deren Bytecode wird zunächst interpretiert und dann von sich selbst in Maschinencode für die aktuelle Rechnerarchitektur übersetzt. Und diese optimierte, superschnelle virtuelle Maschine lädt die Java-Applikation und verfährt mit ihr genauso. Das lässt fast keine Wünsche mehr offen. Nebenbei bemerkt wäre Java nicht Java, wenn viele der Komponenten nicht austauschbar wären. So auch dieser Optimierer (nur für den Fall, dass sich einer selbst versuchen will).

Gratulant

"Als Sun Microsystems 1995 Java präsentierte, verbreiteten sich die Möglichkeiten der neuen Technologie in Fachkreisen wie ein Lauffeuer. Auch ich war überzeugt und wollte von Anfang an dabei sein. Im Sommer 1997 fing ich deshalb bei Sun Microsystems als Systemberater an. Zusammen mit einem deutschen Konzern führte ich eine erste Machbarkeitsstudie durch, denn die Smalltalk-Entwickler waren skeptisch, ob Java auf Servern einsetzbar ist. So sehr mich die Sprache aus dem Stand überzeugte, überrascht mich bis heute die kontinuierliche Entwicklung und der aktuelle Stand mit ihre unglaublichen Möglichkeiten: 2,5 Jahrzehnte später haben circa 1000 Java-Entwickler für den Konzern mit der ersten Machbarkeitsstudie mehr als 500 Anwendungen geschrieben. Auch nach einem Vierteljahrhundert ist das Potenzial von Java nicht ausgeschöpft. Die immer neue Innovationen der abwärtskompatiblen Universalprogrammiersprache sind in ihrer Vielfalt mit einem Leatherman-Multifunktionswerkzeug vergleichbar."

Ein Werkzeug für vieles, aber nicht für alles

So konnten über die Jahre so ziemlich alle Bedenken ausgeräumt werden, warum man Java nicht benutzen sollte. Dabei darf man nicht vergessen, dass Java keine eierlegende Wollmilchsau ist und sein will. Es ist ein Werkzeug, das für viele Probleme eingesetzt werden kann, aber eben nicht für alle. Es wird also auch weiterhin in C, C++, Cobol, Eiffel, Haskel und wie sie nicht alle heißen, programmiert werden. Aber für die, die sich für Java entschieden haben, wird es eigentlich immer nur besser.

Sicherlich hätte man einiges von Anfang an besser angehen können, aber vieles war doch noch unbekannt oder die Zeit noch nicht reif. Java war beispielsweise ein Vorreiter im Umgang mit Unicode. HTML war für die Dokumentation im Programmcode eine aus damaliger Sicht sicherlich vernünftige Entscheidung. Und dass es eine gemeinsame Oberklasse gibt, war damals unumgänglich. Selbst null war unverzichtbar (weil das damals ja auch noch nicht der Milliarden-Dollar-Fehler war). Heute würde man vermutlich das eine oder andere anders umsetzen.

Beispielsweise würde heute das Testen eine größere Rolle spielen. Aber so etwas wie JUnit hat es damals noch nicht gegeben (außer bei Smalltalk). Erst als Java schon einige Jahre auf dem Buckel hatte, entwickelte sich diese besondere Art des Testens, die heute aus dem Entwickleralltag nicht mehr wegzudenken ist. Allerdings hat es ja auch eine IDE im heutigen Sinne nicht gegeben (ja, ja, außer natürlich bei Smalltalk). Aber wie sich auch an der Akzeptanz dieser Art des Testens jenseits von Java zeigte, ein xUnit für eine beliebige Sprache muss keine Sache der Sprache selbst sein.

Statt HTML würde man heute wohl eher zu etwas greifen, was einfacher zu tippen und lesen ist: Markdown zum Beispiel. Wenn man überlegt, wie viel Personenjahrtausende verbraten worden sind, um HTML-Tags auf- und wieder zuzumachen. Mit der heutigen Unterstützung der IDE kann man zwar kaum noch Fehler machen, aber die Online-Version der Java-Dokumentation zeugt immer wieder durch unerwünscht sperrigen, kursiven oder fetten Text davon, das einiges der Dokumentation schon wirklich alt ist.

Das mit der gemeinsamen Oberklasse rächt sich auch immer wieder. Einerseits lässt sich – warum auch immer – jedes Java-Objekt als Lock in einem parallelen Kontext verwenden. Andererseits gibt es jetzt (im Zusammenhang mit Records) eine Reihe von Problemen damit, dass man Objekte auch instanziieren kann, und überlegt, ob der Konstruktor nicht besser nur protected wäre. Dabei sollte aber nicht unterschlagen werden, dass eine gemeinsame Oberklasse notwendig war, um Collections beliebiger Objekte zuzulassen.

Schließlich hat es zu null keine Alternative gegeben. Unabhängig davon wäre es für Java sicherlich nicht förderlich gewesen, allzu esoterisch daherzukommen. Die Ähnlichkeit zu C ohne die verwirrenden Spitzfindigkeiten hat sicherlich zur Akzeptanz von Java beigetragen. Mit so etwas wie Optional statt null zu arbeiten, hätte den meisten Entwicklern damals zu viel abverlangt; und das Drumherum war ja einfach noch nicht weit genug.

Gratulant

"Vor 25 Jahren war Java nur eine weitere Programmiersprache, die ich mir wegen des Internet-Hypes angeeignet hatte und eigentlich keine besonderen Features hatte. Im Gegenteil: Andere Sprachen waren fortgeschrittener oder eleganter. Aber heute beschäftigt mich Java immer noch. Das zeigt die Hauptvorteile: Javas Wandelbarkeit und die tolle Community – und hoffentlich ist diese Technologie deswegen auch noch in 25 Jahren für mich wichtig. Danke für die ersten 25 Jahre und herzlichen Glückwunsch!"