A walk down memory lane Java von ‘95 bis heute

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

New Relic Germany GmbH

Sun Microsystem veröffentlichte 1995 die Programmiersprache Java, um eine portable und interaktive Möglichkeit zur Entwicklung moderner Multimedia-Anwendungen zu schaffen. Die Popularität der Programmiersprache ist ungebrochen – aber wieso? Zeit, die Entwicklung Revue passieren zu lassen.

Ende 1991 initiierten die Sun-Ingenieure James Gosling, Mike Sheridan und Patrick Naughton das Java-Sprachprojekt. Sie nannten sich Green Team. Ursprünglich war die Idee eine Sprache für kleine, eingebettete Systeme in elektronischen Geräten wie Set-Top-Boxen zu entwickeln, das Projekt sollte Greentalk heißen. Der Name war aber nicht passend.

Als nächstes dachte man über Oak (Eiche) nach, weil die Eiche als stark gilt und die Sprache stark und robust sein sollte. Dieser Name war allerdings schon vergeben, also kam James Gosling auf den Namen Java. Java ist eine Insel in Indonesien, auf der der erste Kaffee produziert wurde (Java-Kaffee genannt), eine Art Espressobohne. Und tatsächlich kam Gosling auf den Namen, als er in der Nähe seines Büros eine Tasse Kaffee trank.

Der Unterschied zwischen der Funktionsweise von Java und den meisten anderen Programmiersprachen war revolutionär. Der Code in anderen Sprachen wird zunächst von einem Compiler in Anweisungen für einen bestimmten Computertyp übersetzt. Der Java-Compiler wandelt den Code stattdessen in einen sogenannten Bytecode um, der dann von einer Software namens Java Runtime Environment (JRE) oder der virtuellen Java-Maschine interpretiert wird.

Die JRE fungiert als virtueller Computer, der den Bytecode interpretiert und für den Host-Computer übersetzt. Aus diesem Grund kann Java-Code für viele Plattformen auf die gleiche Weise geschrieben werden („Write one, run anywhere“, z. Dt. „Einmal schreiben, überall ausführen."), was zu seiner Beliebtheit für den Einsatz im Internet beigetragen hat, wo viele verschiedene Computertypen dieselbe Webseite abrufen können.

Durchbruch und Weiterentwicklung

Ende der 1990er Jahre hatte Java Multimedia ins Internet gebracht und begann, über das Web hinauszuwachsen, indem es Verbrauchergeräte (z. B. Mobiltelefone), Computer im Einzelhandel und im Finanzwesen und sogar den Bordcomputer der Mars-Rover der NASA antrieb. Aufgrund dieser Popularität hat Sun verschiedene Java-Varianten für unterschiedliche Zwecke entwickelt, darunter Java SE für Heimcomputer, Java ME für eingebettete Geräte und Java EE für Internetserver und Supercomputer.

Es gibt und gab auch alternative Java-Implementierungen, die über Sun hinausgehen (z. B. JRockit) und IBM mit seiner J9-Implementierung (die jetzt in Eclipse enthalten ist). In der Tat war und ist diese Verbreitung verschiedener, aber sehr spezifischer JVMs ein wesentlicher Bestandteil des Erfolgs des Ökosystems. Im Jahr 2010 übernahm die Oracle Corporation mit der Aqkuisition von Sun Microsystems die Verwaltung des wichtigsten Java-Ökosystems.

Die erste Version von Java wurde im Jahr 1995 veröffentlicht, anschließend folgten etwa im jährlichen Abstand Aktualisierungen. Seit dem Release von Java SE 8 im März 2014 hat sich ein neuer Rhythmus eingeschlichen, jede gerade Version wird im März veröffentlicht und jede ungerade Version im September. Und das sieht dann so aus:

• JDK Alpha and Beta (1995)

• JDK 1.0 (Januar 1996)

• JDK 1.1 (Februar 1997)

• J2SE 1.2 (Dezember 1998)

• J2SE 1.3 (Mai 2000)

• J2SE 1.4 (Februar 2002)

• J2SE 5.0 (September 2004)

• Java SE 6 (Dezember 2006)

• Java SE 7 (Juli 2011)

• Java SE 8 (März 2014)

• Java SE 9 (September 2017)

• Java SE 10 (März 2018)

• Java SE 11 (September 2018)

• Java SE 12 (März 2019)

• Java SE 13 (September 2019)

• Java SE 14 (März 2020)

• Java SE 15 (September 2020)

• Java SE 16 (März 2021)

• Java SE 17 (September 2021)

• Java SE 18 (März 2022)

Alle zwei bis drei Jahre wird eine Java-Version als Long-Term-Support (LTS) eingestuft und erhält nur vierteljährliche Stabilitäts-, Sicherheits- und Leistungsupdates – keine neuen Funktionen. Dazwischen werden weitere Versionen released. Dabei werden die Akzeptanzraten für neuere Versionen immer höher. Während früher LTS-Versionen lange verwendet wurden, egal ob es bereits neuere verfügbare Versionen gab, so zeigt der Release von Java 17 ein Umdenken.

Obwohl Java 11 seit zwei Jahren in Folge an der Spitze steht, übersteigt die Akzeptanz von Java 17 bei Weitem das, was die Entwicklerwelt bei der Einführung von Java 11 sah. Etwa jede elfte Anwendung (9 Prozent) verwendet jetzt Java 17 in der Produktion (gegenüber weniger als einem Prozent im Jahr 2022), was einer Wachstumsrate von 430 Prozent innerhalb eines Jahres entspricht. Es hat Jahre gedauert, bis Java 11 auch nur annähernd dieses Niveau erreicht hat. Diese Zahlen stammen aus dem State of Java Report 2023 von New Relic.

Mehr als 56 Prozent der Anwendungen verwenden jetzt Java 11 in der Produktion (gegenüber 48 Prozent im Jahr 2022 und 11 Prozent im Jahr 2020). Java 8 liegt mit fast 33 Prozent der Anwendungen, die es in der Produktion einsetzen, knapp dahinter (Rückgang von 46 Prozent im Jahr 2022). Nur 0,28 Prozent der Anwendungen verwenden noch Java 7 in der Produktion, was sinnvoll ist, da der Support für Java 7 im Jahr 2022 endete. Bei den meisten Anwendungen, die Java 7 verwenden, handelt es sich um Alt- bzw. Legacy-Anwendungen, die noch nicht aktualisiert wurden.

Container sind überall

Die Containerisierung geht auch an Java nicht vorbei. Inzwischen laufen 70 Prozent der Java-Applikationen in Container-Umgebungen. Das hat zu einem Umdenken in der Verwendung von der Programmiersprache geführt. Denn das System ist, trotz seiner vielen Vorteile, nicht inhärent auf Container eingestellt.

Ingenieurteams verwenden in der Regel kleinere Recheneinstellungen in Cloud-Umgebungen, in denen sie häufig Container einsetzen. Dieser Trend kann jedoch für einige Anwendungen unerwartete Probleme mit sich bringen, die zum Rückgang der Konfiguration beitragen könnten. Wenn Teams beispielsweise mit nur einer CPU arbeiten, erhalten sie möglicherweise nicht den Garbage Collector, den sie erwarten – selbst wenn sie ihn explizit einstellen.

Angesichts ihrer zentralen Rolle für die JVM-Leistung bleibt die Garbage Collection ein heißes Thema in der Java-Gemeinschaft. Ähnliche Trends zeigen sich beim Vergleich der Speichereinstellungen, wobei die Tendenz zu kleineren Instanzen in Containern geht. Die Art der Bereitstellung von Containern führt oft dazu, dass die Entwicklerinnen und Entwickler bewusster auf ihren Fußabdruck achten, da die Grenzen strenger durchgesetzt werden.

Java ist schon lange ein Teil der Development-Welt und wird es vermutlich auch bleiben. Allerdings ist das System durch seine Struktur noch nicht ohne Weiteres in einer Cloud-nativen Welt einsetzbar. Einiges muss beachtet werden, doch es ist zu hoffen, dass auch hierfür bald eine Lösung entwickelt werden kann.

* Jason Clark ist Principal Software Engineer bei New Relic.

(ID:49515563)