25 Jahre Java

Eine Programmiersprache zelebriert ihr Jubiläum
Keine Kommentare

Java wird 25, ein Vierteljahrhundert Java. Ein guter Grund, die heute tief in allen IT-Systemen verwurzelte Programmiersprache zu feiern und einen Blick auf ihre vergangene, gegenwärtige und zukünftige Entwicklung zu werfen.

Es war der 23. Mai 1995, ein Dienstag, als Sun Microsystems, Inc. das erste Java-Release unter dem Namen Java Development Kit 1.0 (JDK 1.0) veröffentlichte. Die Programmiersprache Java umfasste schon damals die Softwareentwicklungsumgebung zur Erstellung von Java-Anwendungen (JDK) und eine Java Virtual Machine (JVM) zur Ausführung von Java-Programmen auf beliebigen Geräten und Betriebssystemen. Damit war der Slogan „Write once, run anywhere“ geboren. Die Java Standard Edition (Java SE) besteht bis heute aus der Kombination von JDK und JVM und wird allgemein als „Java“ bezeichnet.

Plattformunabhängigkeit und Abwärtskompatibilität

Was mit den bekannten Fähigkeiten einer objektorientierten Programmiersprache begann, wurde durch sukzessives Hinzufügen von neuen Merkmalen zu den Java APIs mit ihren Klassenbibliotheken kontinuierlich erweitert. Java läuft nach dem Ansatz einer interpretierten Sprache: Der Java Compiler erzeugt den Bytecode für die JVM, der Java Interpreter führt den kompilierten Bytecode einer Java-Anwendung aus. Durch die Plattformunabhängigkeit vom Java-Bytecode lassen sich die entsprechenden Anwendungen auf jedem unterstützten Betriebssystem ausführen, für das eine JVM existiert.

Förderlich für die Verbreitung der verteilten Programmiersprache Java waren die damalige heterogene Systemlandschaft und die aufkommende Vernetzung. Um tatsächlich portable Anwendungen zu schreiben, wurden sämtliche API-Plattformabhängigkeiten vermieden, indem 100 Prozent reine Java-Programme entwickelt wurden. Ihnen wurde durch die „Pure Java“-Programmzertifizierung durch Sun ihre Portabilität dann auch offiziell bescheinigt. Die ständige Erneuerung der Java APIs mit gleichzeitig gewährleisteter Abwärtskompatibilität ermöglichte Java die direkte Ausführung von älteren, nicht kompilierten Programmen auf einer aktuellen Java-Version. Erst unter Verwendung neuer Sprachfeatures wurde der Compiler angeworfen und existierende Programme wurden schrittweise modernisiert.

Die 25-jährige Reise in eine moderne Java-Anwendungslandschaft war geprägt von intensiven Code-Reviews mit einer gründlichen Evaluierung neuer Features für die jeweiligen Hauptversionen. Einige Meilensteine sind mir dabei in besonderer Erinnerung geblieben.

25 Jahre Java: Meilensteine

  • 1995 Java wird geboren: Nach fünf Jahren interner Entwicklungsarbeit und mehreren Namensänderungen erscheint Java in Version 1.0a2 mit dem HotJava-Browser am 23. Mai 1995 im Hause Sun Microsystems.
  • 1997 Swing löst AWT ab: Als deutliche Modernisierung der GUI-Bibliothek von Java wird Swing zunächst gefeiert. Im weiteren Verlauf stellt sich jedoch heraus, dass es in den meisten Fällen sehr langsam ist und keine gute Optik hat. Grafische Oberflächen bleiben lange ein Schwachpunkt Javas.
  • 1998 JCP wird installiert: Java wurde von Anbeginn an von einer Vielzahl von Unternehmen mitgetragen. Um der gemeinsamen Weiterentwicklung einen ordentlichen Rahmen zu verleihen, wurde der Java Community Process gegründet.
  • 1996 – 1999 EJB, Servlets, JSP standardisieren serverseitige Entwicklung: Ursprünglich für Kaffeemaschinen, Kühlschränke und intelligente Ringe konzipiert, entwickelt sich Java rasch zur serverseitigen Technologie. Zahlreiche proprietäre Ansätze und Workarounds für den Server werden Schritt für Schritt standardisiert.
  • 1999 HotSpot-Compiler bringt JIT/AOT Compiling: Javas größter Schwachpunkt – die mangelhafte Performance bzw. der Ressourcenhunger – erfordert die Neuentwicklung des Runtime-Compilers. Mit einem ausgeklügelten Konzept des Ahead-of-Time-Kompilierens wird eine Technologie entwickelt, die heute noch für Javas Performance zuständig ist.
  • 1999 NetBeans wird von Sun übernommen: In Prag wird seit 1996 an der Universität an einer Java IDE namens Xelphi gearbeitet (in Anlehnung an das damals populäre Borland Delphi), die später als Firma weitergeführt und schließlich von Sun gekauft wird.
  • 1999 Java wird in den drei Editionen ausgeliefert: J2SE, J2EE und J2ME: Auf der JavaOne verkündet Sun Microsystems eine Art „Neustart“ Javas, der von der ansonsten sinnlosen „2“ im Namen ausgedrückt werden sollte. Zukünftig erscheint Java in der „Standard Edition“, der „Enterprise Edition“ und der „Mobile Edition“.
  • 1998 – 2000 Apache wird führende Java-Technologien-Plattform: Tomcat, Struts, Coocon, Maven etc.: Die Anzahl von Java-Projekten auf Apache steigt sprunghaft. Tomcat wird zur Referenzimplementierung für Java Servlets; erstmalig darf dies eine Organisation außerhalb von Sun Microsystems übernehmen.
  • 2000 Erste Mobiltelefone (noch keine Smartphones) mit J2ME-Unterstützung erscheinen auf dem Markt: Die J2ME vereint verschiedene Mobile APIs unter ihrem Dach, ist aber mit den Profilen CDC, CLDC, MIDP, PDAP usw. unübersichtlich, und es gelingt kaum, eine sinnvolle Vereinheitlichung des Programmiermodells zu erreichen.
  • 2001 Eclipse 1.0 erscheint: Aus der „Visual Age Workbench“ macht IBM eine Open Source IDE namens Eclipse. Das Besondere: Es verfügt über einen Plug-in-Mechanismus, über den Toolerweiterungen ergänzt werden können. Die Eclipse-Oberfläche basiert nicht auf Swing, sondern auf dem proprietären SWT (Standard Widget Toolkit), das von IBM entwickelt wurde, um mehr betriebssystemspezifische Anpassungen vornehmen zu können.
  • 2004 Eclipse 3.0 macht OSGi populär: Eclipse basiert jetzt vollständig auf der Java-Modularisierungstechnologie OSGi nach dem Motto „Everything is a Plug-in“. Alle Features der Java IDE sind nichts weiter als Plug-ins, und Eclipse verwandelt sich zur universellen Plug-in-Plattform, auf deren Basis u. a. auch Desktopanwendungen (Eclipse RCP) als Alternative für das schwache Java Swing gebaut werden.
  • 2004 Spring Framework: Mit EJB 3 gerät das serverseitige Java-Komponentenmodell von Sun in die Krise. Da erscheint das Spring Framework, das die Community durch seine Leichtgewichtigkeit und seine Fähigkeit, „Plain Old Java Objects“ (POJOs) auf dem Server zu organisieren, begeistert.
  • 2001 – 2004 Scala, JRuby, Groovy kommen: Als alternative Sprachen für die Java-Plattform erscheinen Scala, JRuby, Groovy und weitere und entfachen einen Hype für Polyglot Programming. Selbst die drei genannten populären Sprachen verbleiben aber bis heute in der Nische.
  • 2004 Höhepunkt der Persistence Wars: Für den Java-Datenzugriff (Object-relational Mapping) existieren konkurrierende Ansätze, deren Vertreter sich teilweise scharfe öffentliche Auseinandersetzungen liefern. Container-managed Persistence, Bean-managed Persistence, Java Date Objects (JDO) und Hibernate stehen zueinander in Konkurrenz.
  • 2005 JPA als Friedensvertrag: Als eine Kompromissformel aus den Ansätzen von EJB (Container- und Bean-managed Persistence), JDO und Hibernate wird die Java Persistence Architecture (JPA) als Standard beschlossen; das Projekt EclipseLink wird zur Referenzimplementierung.
  • 2006 Java soll Open Source werden: Java ist bis 2006 nicht Open Source, sondern basiert lediglich auf einem offenen und inklusiven Entwicklungsmodell, bei dem mehrere Partner Einfluss nehmen. Bis es eine Java-Version gibt, die vollständig auf einem Open-Source-Entwicklungsprozess basiert, sollten bis Java 8 (2014) noch viele Jahre vergehen.
  • 2007 JavaFX wird angekündigt: Ausgerechnet als Antwort auf Adobe Flash kündigt Sun eine Java-GUI-Technologie namens JavaFX an. Sie soll vor allem grafische Darstellungen und Animationen erlauben. Später wird JavaFX als Nachfolger für das in die Jahre gekommene GUI-Toolkit Swing positioniert.
  • 2008 Android erscheint: Android, ursprünglich für Digitalkameras entwickelt und erst spät für die aufkommende Produktgattung Smartphone mit Softtastatur und Multitouch optimiert, wird mit den ersten Geräten ausgeliefert. Es basiert auf einem Linux Kernel und einer Java Runtime, die jedoch nicht lizenziert, sondern als Clone namens Dalvik installiert ist. Das sorgt später für einen heftigen Patentstreit zwischen Oracle und Google.
  • 2010 Oracle kauft Sun Microsystems: Durch die Übernahme von Sun durch Oracle entsteht eine große Verunsicherung in der Java-Community; wie wird es nun mit Java weitergehen? Einige bekannte Mitarbeiter wie James Gosling verlassen das Unternehmen, alles in allem gestaltet Oracle aber die Java-Entwicklung effizienter und führt sie fort.
  • 2013 Docker kommt: Die Containervirtualisierung Docker besteht zwar nicht aus Java-Code, hat aber mächtige Auswirkungen auf die gesamte IT-Branche und nicht zuletzt darauf, wie wir Java-basierende Microservices designen, entwickeln und ausliefern. Ein regelrechter Docker-Hype setzt ein
  • 2014 Java 8 mit Lambdas: Nach mehreren eher enttäuschenden Java-Releases erscheint mit 8 endlich wieder eine Version, die die Entwickler begeistert und mit substanziellen neuen Features wie etwa Lambda Expressions und dem neuen Date-Time API aufwartet.
  • 2015 – 2016 Java-Modularisierung mit OSGi oder Jigsaw? In öffentlichen Schlagabtauschen wird die emotionale Debatte rund um die mit Java 9 kommende Modularisierung geführt. Soll der existierende und von Eclipse her bekannte Java-Modulstandard OSGi gewählt werden oder die Oracle-Entwicklung für Java namens Jigsaw?
  • 2016 MicroProfile: Da Java EE relativ tot wirkt, wird aus der Not eine Tugend gemacht und das Projekt MicroProfile gestartet. Die Initiative für „Enterprise Java für Microservices“ soll als herstellerneutrales Gegengewicht zu Spring Boot & Co. fungieren.
  • 2016 Kotlin erscheint als 1.0: Der Toolhersteller JetBrains hat eine eigene Sprache für die JVM entwickelt, benannt nach einer vor St. Petersburg gelegenen Insel in der Ostsee. Über die Jahre erfreut sich Kotlin steigender Beliebtheit und entwickelt sich zur ersten alternativen JVM-Sprache mit signifikantem Marktanteil in der Java-Welt.
  • 2017 Java 9 mit Modulsystem Jigsaw: Jigsaw hat die „Modularization Wars“ gewonnen und mit 9 liegt die erste vollständig modularisierte Java-Version vor. Die wesentlichen Änderungen finden sich entsprechend in der Architektur und bringen nicht wenige Toolhersteller zum Schwitzen. Bis heute gilt eine Migration auf Java 9 und spätere Versionen als besondere Herausforderung.
  • 2017 Neues Lizenzmodell für Java: Mit Java 9 kommt auch ein neues Lizenzmodell. Nach mehr als 20 Jahren der kostenlosen Nutzung soll die offizielle JVM nun Lizenzgebühren kosten, was für Empörung in der Community sorgt. Mit mehreren alternativen JVMs, unter anderem auch kostenlosen z. B. von AdoptOpenJDK entsteht ein neuer Markt konkurrierender Java Runtimes.
  • 2017 – 2019 Java EE wird zu Jakarta EE: Java EE wird Open Source und wechselt zur Eclipse Fdn. Viel Politik und nahezu zwei Jahre (technologischer) Stillstand. Im September 2019 dann das erste Release: Jakarta EE 8 (funktional identisch zu Java EE 8).
  • 2018 Java 10 mit neuer Releasekadenz: Java 10 ist das erste Major Release der Programmiersprache nach der neuen halbjährlichen Veröffentlichungspolitik. Wichtigstes Feature der neuen Version: Die Syntaxerweiterung Local Variable Type Inference.
  • 2018 Java 11 – Flight Recorder für alle: Java 11 bringt den bis dahin nur kostenpflichtig erhältlichen Java Flight Recorder für alle Nutzer als Teil des OpenJDKs. In Java 11 können zudem auch Lambdaparameter mit dem in Java 10 eingeführten Schlüsselwort var deklariert werden.
  • 2019 – ??? Java bald auf Git und GitHub? Im Zuge von Projekt Skara wird evaluiert, ob Java vom mittlerweile in die Jahre gekommenen Mercurial auf das Versionskontrollsystem Git umsteigen kann. Entsprechende JEPs werden erstellt, und mit Java 16 (Frühjahr 2021) soll der Umzug vollzogen werden.

Funktionale Programmierung mit Lambdas

Mit der Einführung von Lambdaausdrücken und dem Stream API im März 2014 erfuhr die Java SE in Version 8 die größte Sprachänderung seit der Einführung von Generics in Java SE 1.5. Damit wurde die funktionale Programmierung auch für Java ermöglicht und dabei maximale Abwärtskompatibilität sichergestellt. Die Lambdaausdrücke wurden in die Sprachsyntax aufgenommen und mittels invokedynamic-Bytecode implementiert. Lambdas veränderten die Art und Weise, wie Java-Programme geschrieben werden, und es flossen so ab Java SE 8 endlich funktionale Konzepte in die Sprache ein.

Im Grunde repräsentiert ein Lambda eine Funktion. Ein Lambdaausdruck ist eine Instanz eines funktionalen Interface. Der Lambdaausdruck enthält jedoch keine Informationen darüber, welches funktionale Interface er implementiert. Diese Informationen werden aus dem verwendeten Kontext abgeleitet. Im Unterschied zu einer Methode gleicht eine Funktion einer Berechnung, der eine Anzahl von Parametern zugeführt wird und die dann einen Wert zurückliefert. Damit ist es eher ein mathematisches Konzept.

Wichtig ist zu wissen, dass Funktionen auch Nebeneffekte haben können, deshalb war es bei der Implementierung von Lambdaausdrücken in Java 8 besonders wichtig, diese zu vermeiden. Dabei geht es hauptsächlich darum, die Eingangsparameter zu berechnen und dann ein Ergebnis zurückzugeben.

Vor der Veröffentlichung von Java 8 musste jede Berechnung in einer Methode enthalten sein, die wiederum in einer Klasse enthalten war. Der Programmcode war Bestandteil einer Methode. Diese Methode hat einen Namen, der Methodenaufruf erfolgte über die Namensreferenz und möglicherweise auch über die Klasse mit der enthaltenen Methode oder eine Instanz, die mit der Klasse und der darin enthaltenen Methode verbunden war. Somit konnte man Funktionen bisher nur mittels Methoden in Java implementieren.

Durch die Lambdas bekommt man seit Java 8 nun Funktionen, die nicht notwendigerweise fest mit einem Methodennamen innerhalb einer benannten Klasse verbunden sind. Wird die Funktion aus dem strikten Korsett von Methodenname und Klasse herausgelöst, kann man eine Lambdafunktion benutzen und sie als Parameter weiterreichen, als Rückgabewert zurückgeben oder in eine Datenstruktur einbinden. Damit besteht jetzt auch in Java die Möglichkeit, Funktionen zu benutzen, wie es bereits in anderen Programmiersprachen der Fall ist. Funktionen können ineinander verschachtelt sein und Funktionen zurückliefern.

Zur Einführung des Features bot die „Java Magazin Lambda Tour“ die Gelegenheit, die Lambdaausdrücke in der Praxis kennenzulernen und das Programmieren damit zu vertiefen. Die Lambda Tour, inklusive Hackathons, fand in den Städten Duisburg, Hamburg, Frankfurt und München im Herbst 2013 statt. Die Teilnehmer lösten mit den neuen Mitteln kleinere Programmieraufgaben und gewannen dabei erste Erfahrungen mit Lambdas und dem Stream API.

Projekt Jigsaw modularisiert Java

Das im September 2017 erschienene JDK 9 enthielt den modularen Aufbau der Java SE mit dem Java Platform Module System (JPMS). Damit wurde es möglich, die technische Paketierung von ausgewählter Java-Funktionalität selbst zu bestimmen. Das Projekt Jigsaw hatte die primäre Aufgabe, das Design und die Implementierung eines Standardmodulsystems für die Java-Plattform und für das JDK 9 bereitzustellen. Es sollte einfach nutzbar sein, damit die Entwickler das Modulsystem zum Aufbau und zur Wartung von Bibliotheken sowie für große skalierbare Java-SE-Anwendungen verwenden können.

Das Einsatzgebiet von Java SE 9 umfasst die Zielplattformen von Embedded-Geräten, Laptops, Desktops und Servern. Mit dem Werkzeug jdeps wird die Modulabhängigkeitsanalyse im JDK durchgeführt und es können jeweils die Module aufgelistet werden, die eine besondere Abhängigkeit zum Klassenpfad besitzen. Das Werkzeug jlink erzeugt eine individuelle Java Runtime, die inklusive der erstellten Java-Anwendung wesentlich kleiner ist als eine vollständige Java-Laufzeitumgebung (JRE) oder ein komplettes JDK. Die Modularisierung der Java-SE-Plattform im JDK 9 bringt viele Vorteile. Wohlgemerkt, es waren auch einige größere Änderungen damit verbunden: Existierender Anwendungscode, der nur offizielle Java SE Platform APIs mit den unterstützten JDK-spezifischen APIs verwendet, sollte dabei auch weiterhin ohne Änderungen ablauffähig sein.

Nach wie vor war und ist die Abwärtskompatibilität für vorangegangene Hauptversionen mit Java SE gegeben – das gilt auch für die künftigen JDK-Releases mit JPMS. Jigsaw trennt die APIs und die Implementierung von Java-Komponenten und bietet mit diesem Modularisierungsmodell eine bessere Unterstützung für große Projekte an. Die Aufgabe der Java-Anwendungsmodularisierung ist für eine Dekade konzipiert und der Classpath kann weiterhin genutzt werden.

GraalVM – der Grenzüberschreiter im Java-Ökosystem

Durch die GraalVM und ihre Vielsprachigkeit, den JIT Compiler und das Native Image erfuhr das Java-Ökosystem im Jahr 2019 einen Innovationsschub. Die GraalVM bietet für Entwickler und Anwender eine große Chance mit dem Potenzial, die Java-Landschaft grundlegend zu verändern.

Bei der GraalVM handelt es sich um eine universelle virtuelle Maschine (VM) für Anwendungen, die in JavaScript, Python, Ruby, R oder mit den JVM-basierten Programmiersprachen Java, Scala, Kotlin, Clojure sowie LLVM-basierten Sprachen wie C/C++ geschrieben wurden. Neben den jeweiligen Performanceverbesserungen hebt die polyglotte GraalVM die Grenzen zwischen den Programmiersprachen auf und ermöglicht die Interoperabilität in einer gemeinsam genutzten Laufzeitumgebung. Mit dem GraalVM-Native-Image-Tool wird Java-Code via Ahead-of-Time-(AoT-)Kompilierung in Maschinencode konvertiert, der als eigenständige Binärdatei ausführbar ist. Das Native Image ermöglicht niedrige Start-up-Zeiten bei geringem Memory-Bedarf, was für die Ausführung von Microservices Frameworks wie Helidon, Micronaut und Quarkus vorteilhaft ist. Die GraalVM gibt es in zwei Ausführungen: Einerseits die frei einsetzbare und quelloffene GraalVM Community Edition (CE) mit „GPLv2 + Classpath Exception“-Lizenzierung, andererseits die optimierte GraalVM Enterprise Edition (EE) für den produktiven Einsatz mit der kostenpflichtigen OTN-Lizenz. Die GraalVM CE basiert auf dem auf GitHub verfügbaren GraalVM Source Code und kann kostenfrei im Produktivbetrieb eingesetzt werden. Die GraalVM EE ist für Entwicklung, Test, Prototyping und Demozwecke kostenlos nutzbar.

JDK-Lieblingsfeatures

Seit der Einführung vom Oracle JDK 11 im September 2018 und der damit verbundenen Gleichstellung von Oracle JDK 11 und dem Oracle OpenJDK 11 wurden die technischen Unterschiede zwischen den Versionen entfernt. Bei diesem Technologietransfer sind alle Bestandteile vom Oracle JDK als Open-Source-Implementierungen in das Oracle OpenJDK geflossen, sodass das Oracle JDK mit dem Oracle OpenJDK frei getauscht werden kann. Passend zum Oracle JDK 11 und Oracle OpenJDK 11 wurden der JDK Flight Recorder und die JDK Mission Control frei verfügbar angeboten.

JDK Flight Recorder: Die Werkzeuge zum unternehmensweiten Java-Management, die mit JDK 7 im Juli 2011 eingeführt wurden, beinhalten Diagnose- und Monitoringtools für Java-Laufzeitumgebungen. JDK Mission Control ist ein etabliertes Werkzeug für das Monitoring, Profiling und die Diagnose von Java-Anwendungen. Der JDK Flight Recorder ist hingegen mit einem echten Flugdatenschreiber vergleichbar: Die auf ihm gespeicherten Informationen werden wichtig, wenn etwas schiefgelaufen ist.

Auf dem JDK Flight Recorder finden sich kontinuierlich aufgezeichnete Informationen darüber, was auf der Java Virtual Machine passierte, als ein Fehler auftrat. Das Werkzeug kann mit beliebigen Java-Anwendungen und Applikationsservern verwendet werden, von der Entwicklung bis zum produktiven Betrieb. Die einheitliche Datenbasis des Java Flight Recorders ermöglicht es Administratoren und Entwicklern, gemeinsam an Problemlösungen zu arbeiten und Konflikte besser und schneller zu bewältigen.

JEP: Mit dem definierten Oracle-Prozess der JDK Enhancement Proposals (JEPs) gelangen die technischen Verbesserungsvorschläge in das OpenJDK und in das JDK. Die JEP-Struktur dient zur Gestaltung einer langfristigen Java-Feature-Pipeline und der Roadmap für die JDK-Release-Projekte sowie den damit verbundenen Aufwendungen.

NullPointerExceptions: JEP 358 „Helpful NullPointerExceptions“ steht beispielhaft für die stete Verbesserung der Java SE und gehört als lang ersehntes Merkmal zum JDK 14. Bei der Fehlersuche entfällt das lästige Rätselraten, welche Variable null war. Mittels Programm-Bytecode-Command-Analyse erkennt die JVM, welche Variable den Wert null ergibt. Die JVM löst eine NullPointerException (NPE) an einer Programmstelle aus, an der der Code versucht, eine Nullreferenz wieder zu dereferenzieren. Durch die Analyse der Programmbytecodeanweisungen ermittelt die JVM dann, welche Variable null war, und beschreibt die Variable in Bezug auf den Quellcode mit einer Null-Detail-Nachricht in der NPE. Diese Information gelangt dann zusammen mit der Methode, dem Dateinamen und der Zeilennummer zur JVM.

Records: Mit der Einführung von Record-Typen (JEP 59) im Jahr 2020 gelangte ein brauchbares Feature als Preview in das JDK 14. Die Records wurden im Rahmen des Projekts Valhalla entwickelt. Ähnlich wie Enums lassen sich Records mit einer eingeschränkten Form von Klassen vergleichen und erlauben das Ersetzen einer einfachen Datenklasse durch Records mit Datenkapselung. Records deklarieren ihre Repräsentation und sie bestätigen diese Darstellung an das zugehörige API. Dabei werden Freiheiten einer Klasse, also etwa die Fähigkeit, das API von seiner Repräsentierung zu entkoppeln, bewusst aufgegeben. Im Gegenzug dazu erhält man mit Records einen signifikanten Grad an Präzision: Was zusammengehört, bleibt zusammen.

JavaFX und Swing

Der Status von Java Swing, das über die Java Foundation Classes im Jahr 1997 eingeführt wurde, ist unverändert und bedeutet, dass Java Swing ein Bestandteil von Java SE 8 ist und der Support gemäß Java SE Support Roadmap bis zum März 2030 läuft. Beim JDK 11 steckt Java Swing im Modul java.desktop.jmod, hierfür erstreckt sich der Support bis zum September 2026.

Seit der Vorstellung von JavaFX 2.0 auf der JavaOne 2011 hat die UI-Technologie für Java-Client-Anwendungen eine konstante Anzahl von Entwicklern begeistern können. Im Herbst 2012 wurden erste namhafte JavaFX-Anwendungsbeispiele vorgestellt, dicht gefolgt von weiteren Geschäftsanwendungen, die später mit JavaFX 8 realisiert wurden. Im Jahr 2013 ging die bislang proprietäre UI-Technologie vollständig in Open Source auf und fand ihr Zuhause für die Entwicklung im OpenJDK-Projekt OpenJFX [3].

Mit der Bündelung von JavaFX 8 und Java SE 8 (JRE/JDK) im März 2014 wurde die Versionierung von JavaFX/OpenJFX und Java SE vereinheitlicht. Aufgrund der JavaFX 8 Roadmap erhält die Zusammenarbeit mit der JavaFX-Developer-Community und ihren signifikanten Entwicklungsbeiträgen einen hohen Stellenwert für den Fortbestand von JavaFX/OpenJFX.

Durch die Java-Modularisierung wurde JavaFX 11 aus dem JDK 11 herausgelöst und fortan von Oracles JavaFX-Engineering-Team und von Gluon gemeinsam gepflegt. JavaFX wird seitdem separat zum Oracle JDK hinzugefügt und OpenJFX passt mit dem OpenJDK zusammen.

Der Download von JavaFX 11 (LTS) und höheren Versionen erfolgt über eine separate Webseite. JavaFX 14 wird als eigenständiges Release über den Entwicklungspartner Gluon angeboten und kann als Open-Source-Software mit dem Oracle OpenJDK oder wahlweise mit dem Oracle JDK 14 und dem Java SE Subscription Support betrieben werden. Über Gluon wird ein dezidierter Support für JavaFX angeboten. Die JavaFX-Module können mit dem javafx-sdk-14 (SDK) über den Java Module Path integriert werden oder über die JavaFX 14 JMODs, die mit dem Werkzeug jlink in eigene Anwendungen eingebunden werden.

Beeindruckend sind der Aufwärtstrend der JavaFX-UI-Technologie mit den ansteigenden Downloads bei Maven Central im Jahr 2019 und die konkreten Projektdiskussionen beim JavaFX-Anwendertreffen 2018 in München sowie auf den JFX Days 2019 in Zürich.

Dank der GraalVM und der darin enthaltenen Native-Image-Funktionalität können jetzt auch kleinere und vor allem leistungsfähigere JavaFX-Anwendungen mit der aktuellen JDK-Version und der korrespondierenden JavaFX-Version erstellt werden. Damit ist ein Cross-Plattform-Deployment möglich, die Plattformen iOS und Android werden mit Java durch Gluon Mobile abgedeckt.

Von Konferenzen und Verwaltungssystemen

Die JavaOne-Konferenz wurde im Jahr 1996 erstmals von Sun Microsystems veranstaltet, um alle relevanten Java-Themen zu diskutieren. Die weltweite Entwicklerkonferenz, die immer in San Francisco stattfand, gab über viele Jahre den Takt zur Weiterentwicklung der Programmiersprache Java vor. Die Begeisterung der Entwickler erreichte ihren Höhepunkt im Jahr 2001 mit 25 000 Teilnehmern im Moscone Center. Die Obergrenze hatte der Feuerwehrchef von San Francisco aus Brandschutzgründen ausgegeben, und tatsächlich waren exakt 25 000 Teilnehmer im Gebäude versammelt, sodass das Gebäude nicht geräumen werden musste.

Die Oracle Code One hat die frühere JavaOne im Jahr 2018 als Nachfolgekonferenz abgelöst. Sie ist auf verschiedene Programmiersprachen, Technologien und Entwicklercommunitys ausgerichtet. Bei ihrer Premiere lag der Fokus auf den Code Contributions durch Entwickler via GitHub, natürlich auch auf Java selbst und auf der weltweiten Zusammenarbeit der Java-Community im OpenJDK.

Das Projekt Skara wurde vor Ort von GitHub vorgestellt. Die Community arbeitet dabei an der Umsetzung eines alternativen Source-Code-Management-Systems mit Code-Review-Optionen für den JDK-Quellcode, das anstelle von Mercurial das beliebtere Git nutzt. In der GitHub-Skara-Demo wurde ein Codeupdate mit einem JDK 10-Feature in einem älteren Java-Programm durchgeführt, dann der Pull Request erzeugt und die Änderung analysiert. Die Demo verdeutlichte so die einzelnen Verbesserungen mit GitHub bei der Java-Entwicklung und unterstützt damit einen unkomplizierten Zugang zu den Java Repositories.

In Übereinstimmung mit JEP 357 (Migration von Mercurial zu Git) hat JEP 369 die Aufgabe, alle OpenJDK-Projekte mit einem Repository zu GitHub zu migrieren. Letzteres gilt einschließlich der JDK-Feature-Releases sowie der JDK-Update-Releases für Version 11 und höher. Diese beiden JDK-Verbesserungsvorschläge sind als Bestandteil für das JDK 16 vorgeschlagen.

Fazit und Ausblick

Mit dem sechsmonatigen Java-Release-Zyklus wird angestrebt, dass neue Features schneller bereitgestellt werden können und die Java-Feature-Releases zueinander passen. Außerdem soll sichergestellt werden, dass Nicht-LTS-Releases den Ruf „experimenteller“ Versionen verlieren und und die als „deprecated“ markierten Features nicht einfach aus Zwischenreleases verschwinden.

Die Erfahrungen beim Umstieg von JDK 8 auf JDK 11 haben gezeigt, dass die Variante „just run“ praktisch nutzbar ist. Das heißt, dass existierende Java-Anwendungen dank Abwärtskompatibilität ohne Modifikation mit dem höheren Java-Release ablauffähig sind.

Dennoch muss man in seltenen Fällen die Möglichkeit einer Unverträglichkeit in Betracht ziehen, wenn auch nur in Randbereichen. Mit der Variante „Neukompilieren und Quellcode anpassen“ wird der alte Java-Code immer auf dem aktuellen Stand der Technik gehalten und durch die gängigen Entwicklungsumgebungen bestmöglich unterstützt.

Der Oracle JDK Migration Guide bietet dem Entwickler praktische Hilfen bei der Migration von JDK 8 auf JDK 11 oder JDK 17 (LTS). Die künftige Feature-Pipeline für Java ist gut gefüllt. Die Inhalte der Projekte Amber (Right-sizing Language Ceremony), Valhalla (Value Types und Specialized Generics), Panama (Foreign Function/Data Interface), Loom (Continuations in der JVM und Fibers im JDK) und Project Leyden (Static Images für das JDK) stellen dies unter Beweis.

Unabhängig davon, ob Java on premises oder in der Cloud eingesetzt wird, liegt es in der Hand der Community, wie wir die nächsten 25 Jahre gestalten möchten und wohin Java steuert.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -