zurück zum Artikel

Heute vor 25 Jahren wurde die Programmiersprache Java der Weltöffentlichkeit vorgestellt. Eine Würdigung zum Jubiläum von Michael Wiedeking.

Ich hatte das Vergnügen, mich mit Java zu beschäftigen, noch bevor es am 22. Mai 1995 öffentlich bekannt gemacht wurde. Der Leiter des Sun-Schulungszentrums wusste um meine Vorliebe für Programmiersprachen und brachte mich mit dieser neuen Sprache in Verbindung. Warum ich dann die nächste Zeit damit beschäftigt sein würde, hauptsächlich programmierunerfahrenen Sun-Vertrieblern Java näher zu bringen, ist mir heute noch schleierhaft; aber immerhin hatten es trotz aller Widrigkeiten fast alle geschafft, mit einer Reihe von GIF-Bildern eine Animation auf den Netscape-Browser zu zaubern.

Von 1995 bis heute

Michael Wiedeking ist Gründer der MATHEMA Software GmbH und des Herbstcampus sowie Herausgeber des KaffeeKlatsch. Er ist Java-Programmierer der ersten Stunde, schreibt regelmäßig Artikel und spricht auf Konferenzen im In- und Ausland. Am liebsten "sammelt" er Programmiersprachen und beschäftigt sich mit ihrem Design und ihrer Implementierung.

Seitdem hat sich einiges geändert. Die wichtigste Schnittstelle eines dynamischen WWW ist nicht mehr CGI (Common Gateway Interface), mit sich bewegenden Bildern kann man niemanden mehr hinterm Ofen hervorlocken. Und das sofortige Validieren von Benutzerangaben kann man – wenn man möchte – heutzutage auch über ein Programm machen, das unter Linux läuft, das auf einem emulierten 8086-Computer installiert ist, der vollständig in JavaScript geschrieben ist. Ein Vierteljahrhundert ist dann doch eine ganz schön lange Zeitspanne.

Von Versprechen und eigentlichem Benefit

Das Geniale an Java war damals nicht etwa das Versprechen, dass ein einmal geschriebenes Programm auf allen Betriebssystem läuft (Write Once, Run Anywhere); es waren der Komfort und die Einfachheit, mit der Java den Blick auf Software geändert hat. Ich erinnere mich noch vage daran, wie eigentümlich es war, unter Unix eine Netzwerkverbindung aufzubauen. Unter Java:

Socket s = new Socket(host, port);

Fertig! Aber das ist ja auch fast zu einfach. Wie sieht es denn auf der Serverseite aus?

ServerSocket ss = new ServerSocket(port);
Socket s = ss.accept();

Voilà! Und das steht repräsentativ für (fast) alles, was mit Java zu tun hat.

Gratulant

"Ich hab mit Java angefangen, ohne es richtig zu realisieren. Meine Wurzeln waren in der Webentwicklung mit Perl und klassischem HTML, und zu Java bin ich über den Umweg einer übergelagerten Plattform (J2EE) gekommen. Für mich war es immer unglaublich zu sehen, wie eine "einfache" Programmiersprache so viel mehr Möglichkeiten durch die Zusatzfunktionen der Plattform bekam und welche unglaublich komplexen Anforderungen sich damit bewältigen ließen. Und das alles auf den Fundamenten einer offenen, freundlichen und starken Gemeinschaft. Was in den Anfängen noch sehr von Sun und weiter Oracle diktiert wurde, hat mit der Öffnung des OpenJDK noch viel mehr Auftrieb bekommen. Wenn ich mir so vor Augen führt, dass es vor Java quasi keine einzige kostenlose und freie Entwicklungssprache gab, die sich bei komplexen Enterprise-Problemen einsetzen ließ, und realisiere, welches wirklich unglaubliche Ökosystem nach fast einem Vierteljahrhundert entstanden ist, bin ich ein klein wenig Stolz, die Gelegenheit zu haben, auch ein Teil davon zu sein."

Wenn da nicht die Performance wäre

Ich höre jetzt natürlich die "Ja, aber…"-Zurufe. Beispielsweise lies es sich dann doch nicht so einfach an den kleinen Schräubchen drehen: Time-out, Puffergrößen usw. Aber in 90 Prozent der Fälle kam man damit zurecht, und wenn nicht, dann gab es ja noch das Java Native Interface (JNI), mit dessen Hilfe man sich nach wie vor in C austoben konnte. Und das war aus Performancesicht dringend nötig.

Java war in den meisten Fällen zwar schnell genug, aber weit davon entfernt, schnell zu sein. Frei nach dem Motto "Not macht erfinderisch" wurden dann auch alle Register gezogen. Bei uns entstand die Not etwa dadurch, dass wir evaluieren sollten, ob eine Bearbeitung von Bildern mit über einer Millionen Bildpunkte unter einer Sekunde möglich wäre. Eine für die damalige Zeit übliche Lösung war das Weglassen der Abbruchbedingungen bei der Bearbeitung eines Arrays:

try for (int i = 0;; i++) {
    f(a[i]);
} catch (ArrayIndexOutOfBoundsException e) {
    ;
}

Der Verzicht auf die explizite Überprüfung der Grenzen, was Java sicherheitshalber bei dem Zugriff auf das Array ohnehin machte, brachte dann den nötigen Performancegewinn. Die Applikation, die Ärzten Röntgenbilder via Applet zur Verfügung stellen sollte, wurde dann aber mangels Netzbandbreite im letzten Jahrtausend doch nicht gebaut.

Ein aufmerksamer Leser wird bemerken wollen, dass hier wohl zwischen dem try und dem for eine Klammer fehlt. Aber tatsächlich war das in den allerersten Versionen nicht nötig, weil der Compiler einen Fehler hatte. Derer gab es auch noch einige mehr, von denen nur der private protected-Fall namentlich erwähnt werden soll, weil dieser in der ersten Version von dem legendären "Java in a Nutshell"-Buch dokumentiert ist. Schade, dass man diesem Fehler zugunsten nicht die Spezifikation geändert hat, hätte er doch Klassen im selben Paket nur dann den Zugriff auf derartig annotierte Felder und Methoden gewährt, wenn sie ererbt worden wären.

Heute sind "Optimierungen" wie das Weglassen von Bedingungen, das Pooling von Objekten et cetera hochgradig kontraproduktiv, sodass man wirklich alles richtig machen darf. Wobei sich auch hier die Geister scheiden, wie man etwas richtig macht. Ob man Getter oder Setter verwenden soll, obwohl sie für das Bean-Modell von Java essenziell sind, oder ob man Vererbung nutzen soll oder doch lieber auf Komposition setzt. Letztlich ist das aber egal; wesentlich ist doch, dass man so ziemlich alles mit Java machen kann.

Gratulant

"25 Jahre Java. (M)Ein halbes Leben begleitet du mich mittlerweile. Angetreten als Universallösung für programmierbare Türen, Kühlschranke, Ringe oder Kreditkarten hast du einen nicht immer einfachen Weg hinter dir. Wer hätte dir zum Beispiel zur Jahrtausendwende zugetraut, dass du jemals den Desktop verlassen und auf den Servern dieser Welt deinen Dienst tun würdest? Oder wer hätte damit gerechnet, dass du "verkleidet" als Android einmal den Markt der Mobile Devices erobern wirst? Und selbst in Zeiten von Cloud-native und Serverless, in denen dich viele Abtrünnige bereits totgesagt haben, ist dir mit GraalVM und Quarkus ein Comeback gelungen. Egal welche Herausforderungen in den letzten 25 Jahren auf dich warteten, am Ende hast du immer wieder einen Weg gefunden, dich für mich und den Rest der Welt interessant zu machen. Dafür danke ich dir und natürlich der sagenhaften Community um dich herum, dessen Teil sein zu dürfen ich froh und stolz bin! Ich freue mich auf die kommenden Jahre mit dir und darauf, wohin der Weg uns beide gemeinsam führen wird."

Unterschätzt: die Dokumentation

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!"

Fortwährendes Lernen und Arbeiten

Syntaktisch gesehen hinterlässt Java inzwischen einen etwas holprigen Eindruck. Den Anfang der Abstrusität stellen die anonymen inneren Klassen dar. Aktuell versuchen sich der switch-Ausdruck und das Pattern Matching gegenseitig zu überbieten. Die Syntax einer Sprache zu ändern gestaltet sich aber auch nicht besonders trivial. Beispielsweise hätten viele gerne ein Smart Cast wie in Kotlin.

Object o = …
if (o instanceof String) {
      ... o.length() … // o ist jetzt sicher ein String
   }

Das geht in Java leider nicht, weil sich sonst alte Java-Quellen zwar noch übersetzen ließen, sich möglicherweise aber das Verhalten des Programms ändert. Also macht man es so:

Object o = …
if (o instanceof String s) {
        ... s.length() … // na ja
    }

Wie oben schon angedeutet, zeichnet sich Java eben auch dadurch aus, dass bei allen Erweiterungen die Altbestände nicht gefährdet sind. Eine für ein Vierteljahrhundert in unserer Branche wahrlich beeindruckende Leistung.

Bewährte Partnerin

Ich habe die letzten 25 Jahre gerne mit Java gearbeitet. Nach der anfänglichen Euphorie als C/C++-Programmierer haben sich zwar auch Schwächen gezeigt, aber die ließen sich umgehen werden oder wurden im Laufe der Zeit getilgt. Im Gegensatz zu den C-Programmen ist mir die virtuelle Maschine nur dreimal abgestürzt, und das auch nur, weil ich Experimente mit der vielversprechenden Klasse mit dem Unheil verheißenden Namen Unsafe gemacht habe.

Was erwartet man von einer solchen "Partnerschaft": eine Sprache, die offen ist, sich weiterentwickelt und an die neuen Gegebenheiten anpasst, sich dabei aber treu bleibt und die eigenen Prinzipien nicht vergisst. Was will man mehr? Und die Zukunft verspricht noch spannender zu werden, mit all den Projekten die schon in der Java-Pipeline stecken. So freue ich mich jetzt schon auf die nächsten 25 Jahre.

Siehe dazu auf heise Developer:

• Heute vor 20 Jahren: Java betritt offiziell die Bühne [9]

Sie wollen selbst gratulieren oder Ihre Erfahrungen mit Java teilen? heise Developer freut sich über Ihren Kommentar oder eine Mail an die Redaktions-E-Mail-Adresse [10]. (ane [11])

URL dieses Artikels:
https://www.heise.de/-4726151

Links in diesem Artikel:
[1] https://www.heise.de/news/Sun-enthuellt-neues-Java-Konzept-17145.html
[2] https://www.heise.de/hintergrund/Der-Tiger-ist-los-506330.html
[3] https://www.heise.de/news/Java-als-Open-Source-Java-unter-der-GPL-und-ein-Community-Projekt-117233.html
[4] https://www.heise.de/news/Oracle-stellt-Java-Plattform-7-vor-1288084.html
[5] https://www.heise.de/blog/Alles-auf-8-Java-SE-8-ist-da-2149753.html
[6] https://www.heise.de/news/Java-9-ist-fertig-3837080.html
[7] https://www.heise.de/news/Jakarta-EE-Eclipse-Foundation-uebernimmt-die-Verantwortung-fuer-Enterprise-Java-4030557.html
[8] https://www.heise.de/news/Java-11-bringt-nicht-nur-ein-geaendertes-Supportmodell-4173024.html
[9] https://www.heise.de/news/Heute-vor-20-Jahren-Java-betritt-offiziell-die-Buehne-2652463.html
[10] mailto:developer@heise.de
[11] mailto:ane@heise.de

Copyright © 2020 Heise Medien