Oracle vermarktet auf der Basis vom OpenJDK ihr eigenes Projekt OracleJDK. Ab Java 11 sind das OracleJDK und OpenJDK vom Code her identisch. Das Oracle JDK ist die »offizielle« Version, die die Java-Download-Seite von Oracle anbietet.

Long Term Support (LTS)

Die halbjährlichen Java-Releases haben zur Folge, dass Versionen immer dann veraltet sind, wenn eine neue Version erscheint. In dem Moment, in dem Java 10 kam, war Java 9 veraltet, das gleiche ist bei Java 11, es machte sofort Java 10 zur alten Version. Das allein wäre kein Problem, wenn die älteren Versionen mit Sicherheitsupdates versorgt würden, aber Oracle investiert für die Allgemeinheit in die alten Versionen keine Zeit und Mühe mehr.

Für Unternehmen ist das ein Problem, denn es erzeugt Stress, mit den Änderungen mitziehen zu müssen. Aus diesem Grund bietet Oracle alle drei Jahre eine Java-Version mit Long Term Support (LTS) und versorgt sie mit Updates und Sicherheitspatches. Die nächsten LTS-Versionen nach Java 8 ist Java 11 (September 2018) und dann nach 3 Jahren Java 17 (September 2021). Das ist für weniger agile Unternehmen gut. Oracle will ihre Java SE 8-Implementierung noch bis mindestens Dezember 2020 pflegen, geplant ist bis März 2025[1] und Java 11 bis 2023, beides Releases mit LTS.

Kommerzialisierung vom OracleJDK

Auf den ersten Blick sieht das gut aus: es gibt regelmäßige Updates für agile Unternehmen und die konservativen Unternehmen setzen auf eine LTS-Version. Der Problem ist allerdings, dass alle OracleJDK-Versionen nicht kommerziell eingesetzt werden dürfen; der Hersteller erlaubt die Nutzung nur für „development, testing, prototyping or demonstrating purposes“. Für Java 8 endet die Schonfrist im Januar 2019.

Wer das OracleJDK kommerziell einsetzen möchte, und nicht nur in einer Entwicklungs- oder Testumgebung, muss eine Lizenz von Oracle erwerben. Es wird monatlich abgerechnet, die Vertragszeit ist mindestes in Jahr. Es stehen zwei Modelle zur Auswahl:

Java SE Subscription	Java SE Desktop Subscription
Für Serveranwendungen	Für Client-Anwendungen
Abrechnung pro Prozessor	Abrechnung pro Benutzer
ab 25 USD/Monat, für 1-99 Benutzer	ab 2,50 USD/Monat für 1-999 Benutzer/Clients

Tabelle: Zwei Lizenzmodelle für Oracle Java SE

Oracle wendet bei der Java SE Subscription das gleiche Geschäftsmodell wie bei der Oracle-Datenbank an. Wie genau Rechner in der Cloud mit einer unbestimmten Anzahl der Prozessoren abgerechnet werden soll ist noch unklar.[2] Interessenten sollten die „Oracle Java SE Subscription FAQ“ unter http://www.oracle.com/technetwork/java/javaseproducts/overview/javasesubscriptionfaq-4891443.html studieren und Oracle-Berater hinzuziehen. Wer Client- und Serveranwendungen nutzt, muss zweimal bezahlen, statt »write once, run anywhere«, »write once, pay everywhere«.

Die Kosten können sich schnell summieren, doch bekommen Unternehmen damit Support und insbesondere für Java 8 immer noch für einige Jahre Unterstützung. Nachteil ist, dass es das Subscription-Modell nur für die LTS-Versionen gibt, Unternehmen also gezwungen werden, größere Versionssprünge zu machen. Nach Java 11 kommt erst im September 2021 die Version Java 17 mit dem nächsten LTS.

Java Platform, Standard Edition in drei Paketen: JDK, JRE, Server JRE

In der Oracle Java SE-Familie gibt es verschiedene Ausprägungen: das JDK und das JRE. Da diejenigen, die Java-Programme nur laufen lassen möchten, nicht unbedingt alle Entwicklungstools benötigen, hat Oracle Pakete geschnürt:

• Mit dem Java Development Kit (JDK) lassen sich Java SE-Applikationen entwickeln. Dem JDK sind Hilfsprogramme beigelegt, die für die Java-Entwicklung nötig sind. Dazu zählen der essenzielle Compiler, aber auch andere Hilfsprogramme, etwa zur Signierung von Java-Archiven oder zum Start einer Management-Konsole. In den Versionen Java 1.2, 1.3 und 1.4 heißt das JDK Java 2 Software Development Kit (J2SDK), kurz SDK, ab Java 5 heißt es wieder JDK.
• Das Java SE Runtime Environment (JRE) enthält genau das, was zur Ausführung von Java-Programmen nötig ist. Die Distribution umfasst nur die JVM und Java-Bibliotheken, aber weder den Quellcode der Java-Bibliotheken noch Tools wie Management-Tools.
• Das Server JRE ist für 64-Bit-Server-Umgebungen gedacht und enthält anders als das herkömmliche JRE nicht den Auto-Updater, das Plugin-Tool oder einen Installer. Wie das JDK enthält es hingegen eine Management-Konsole.

Die drei Produkte können von der Webseite http://www.oracle.com/technetwork/java/javase/downloads/ bezogen werden – die Lizenzbestimmungen sind einzuhalten.

Oracle JDK 10 Certified System Configurations

Eine ideale, perfekt getestete und unterstützte Umgebung gilt als Oracle Certified System Configuration. Das ist eine Kombination aus Betriebssystem mit installierten Service-Packs; das beschreibt das Unternehmen unter https://www.oracle.com/technetwork/java/javase/documentation/jdk10certconfig-4417031.html. Bei gemeldeten Bugs auf nicht zertifizierten Plattformen kann dann schnell ein »Sorry, das ist eine nicht unterstützte Plattform, das schauen wir uns nicht weiter an« folgen. Bei Linux ist zum Beispiel die Gentoo-Distribution nicht in der Liste, wäre also »Not certified on Oracle VM«. Das heißt nicht, dass Java dort nicht zu 100 % läuft, nur, dass es im Fehlerfall eben keinen Fix geben muss.

[1] http://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf

[2] http://houseofbrick.com/the-oracle-parking-garage/ ist dann gar nicht mehr zum Lachen …

Das freie und unter der GPL stehende OpenJDK (http://openjdk.java.net/) bildet die Referenzimplementierung für Java SE. Alle Entwicklungen finden dort statt. Der Fortschritt ist live zu beobachten, regelmäßig fixen und erweitern Hunderte von Entwicklern die Codebasis. Die Quellen für das OpenJDK lassen sich im Mercurial Repository unter http://hg.openjdk.java.net/jdk/jdk11 einsehen, ein Wechsel auf GitHub wird diskutiert.

OpenJDK-Builds von Oracle

Übersetzte Versionen sind über http://jdk.java.net/ verklinkt, es gibt von Oracle OpenJDK x64-Builds für

• Windows
• Linux
• macOS
• Alpine Linux

OpenJDK-Builds von AdoptOpenJDK

Auch unter https://adoptopenjdk.net/ lässt sich für unterschiedliche Betriebssysteme eine Version herunterladen. Angeboten werden x64-Builds für

• Windows
• Linux
• macOS
• Linux s390x
• Linux ppc64le
• Linux aarch64
• Linux arm32
• AIX ppc64

AdoptOpenJDK ist eine Serverfarm, die regelmäßig Builds vom OpenJDK baut, dazu weitere Software wie die JavaFX-Implementierung OpenJFX und alternative Laufzeitumgebungen wie Eclipse OpenJ9 einbindet.

Weitere OpenJDK-Builds

Das Unternehmen Azul bietet ebenfalls Builds an, auch lässt sich ein Support-Vertrag abschließen: http://www.azul.com/downloads/zulu/. Neben den Plattformen Windows, Linux und macOS gibt es von Azul ebenfalls Docker-Images.

Red Hat bietet neben Linux auch eine Windows-Version vom OpenJDK an: http://developers.redhat.com/products/openjdk/overview/.

Apple pflegte lange Zeit eine komplett eigene JVM, bis Apple den Code an Oracle für das OpenJDK übergab. Auch Google setzt bei Android neuerdings auf das OpenJDK.

OpenJDK unter Windows installieren

Während Oracle ein JDK und ein JRE anbietet und alles mit einem Installationsprogramm ausliefert, kommt das OpenJDK nur als  komprimiertes Archiv. Wir laden von http://jdk.java.net/10/ für Windows die TAR.GZ-Datei, hinter der eine Datei wie openjdk-10.0.2_windows-x64_bin.tar.gz steckt. Wir benötigen einen Entpacker wie 7-Zip für das unter Windows ehr ungewöhnliche Dateiformat.

Programme und Ordner im Java-Verzeichnis

Nach dem Auspacken entsteht ein Ordner jdk-10.0.2 mit dem OpenJDK. Es enthält ausführbare Programme wie Compiler und Interpreter sowie die Bibliotheken und Quellcodes. Wenn wir die Rechte haben, wollen wir den JDK-Ordner in der Windows-Programmorder setzen und für die weiteren Beispiele folgenden Ort annehmen: C:\Programme\Java\jdk-10.

Ordner/Datei	Bedeutung
bin	Hier befinden sich Entwicklungswerkzeuge, unter anderem der Interpreter java und beim JDK der Compiler javac.
conf	Konfigurationsdateien, Anpassungen sind hier selten nötig.
include	Dateien für die Anbindung von Java an C(++)-Programme
jmods	Java-Module vom JDK, etwa das Basis-Modul
legal	eine Reihe von COPYRIGHT-Textdateien
lib	interne JDK-Tools
lib/src.zip	Archiv mit dem Quellcode der öffentlichen Bibliotheken*
release	Datei mit Schüssel-Wert-Paaren

Tabelle: Ordnerstruktur

Testen der Installation und Pfade setzen

Gehen wir in das bin-Verzeichnis C:\Program Files\Java\jdk-10\bin können wir aufrufen:

C:\Program Files\Java\jdk-10\bin>java -version

openjdk version „10.0.2“ 2018-07-17

OpenJDK Runtime Environment 18.3 (build 10.0.2+13)

OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode)

Wir erweitern als nächstes die PATH-Variable um das bin-Verzeichnis. Wenn wir jetzt eine Shell öffnen, können wir javac für den Java-Compiler aufrufen oder java für die Laufzeitumgebung. Auch kann eine Entwicklungsumgebung wie Eclipse gestartet werden.

OpenJDK deinstallieren

Nach dem Löschen des Ordners ist Java deinstalliert.

Download der Dokumentation

Die API-Dokumentationen der Standardbibliothek und die der Tools sind kein Teil des JDK; eine Trennung ist sinnvoll, denn sonst würde der Download nur unnötig größer, die Dokumentation kann schließlich auch online angeschaut werden. Die Hilfe kann online unter https://docs.oracle.com/javase/10/docs/api/ eingesehen oder als ZIP-Datei extra bezogen und lokal ausgepackt werden.

Die Java Platform, Standard Edition (Java SE) ist eine Systemumgebung zur Entwicklung und Ausführung von Java-Programmen. Java SE enthält alles, was zur Entwicklung von Java-Programmen nötig ist. Obwohl die Begrifflichkeit etwas unscharf ist, lässt sich die Java SE als Spezifikation verstehen und nicht als Implementierung. Damit Java-Programme übersetzt und ausgeführt werden können, müssen aber ein konkreter Compiler, Interpreter und die Java-Bibliotheken auf unserem Rechner installiert sein. Es gibt unterschiedliche Implementierungen, etwa das OpenJDK.

Versionen der Java SE

Am 23. Mai 1995 stellte damals noch Sun Java erstmals der breiten Öffentlichkeit vor. Seitdem ist viel passiert, und in jeder Version erweiterte sich die Java-Bibliothek. Dennoch gibt es von einer Version zur nächsten kaum Inkompatibilitäten, und fast zu 100 % kann das, was unter Java n übersetzt wurde, auch unter Java n + 1 übersetzt werden – nur selten gibt es Abstriche in der Bytecode-Kompatibilität.[1]

Version	Datum	Einige Neuerungen oder Besonderheiten
1.0	Januar 1995	Erste Version. Folgende 1.0.x-Versionen lösen diverse Sicherheitsprobleme.
1.1	Februar 1997	Neuerungen bei der Ereignisbehandlung, beim Umgang mit Unicode-Dateien (Reader/Writer statt nur Streams), außerdem Datenbankunterstützung via JDBC sowie innere Klassen und eine standardisierte Unterstützung für Nicht-Java-Code (nativen Code)
1.2	November 1998	Es heißt nun nicht mehr JDK, sondern Java 2 Software Development Kit (SDK). Swing ist die neue Bibliothek für grafische Oberflächen, und es gibt eine Collection-API für Datenstrukturen und Algorithmen.
1.3	Mai 2000	Namensdienste mit JNDI, verteilte Programmierung mit RMI/IIOP, Sound-Unterstützung
1.4	Februar 2002	Schnittstelle für XML-Parser, Logging, neues IO-System (NIO), reguläre Ausdrücke, Assertions
5	September 2004	Das Java-SDK heißt wieder JDK. Neu sind generische Typen, typsichere Aufzählungen, erweitertes for, Autoboxing, Annotationen.
6	Ende 2006	Webservices, Skript-Unterstützung, Compiler-API, Java-Objekte an XML-Dokumente binden, System Tray
7	Juli 2011	Kleine Sprachänderungen, NIO2, erste freie Version unter der GNU General Public License (GPL)
8	März 2014	Sprachänderungen Lambda-Ausdrücke, Stream-API
9	September 2017	Modularisierung von Anwendungen
10	März 2018	Lokale Variablendeklarationen mit var
11	September  2018	Entfernung des java.ee-Moduls

Tabelle 1.1: Neuerungen und Besonderheiten der verschiedenen Java-Versionen

Die Produktzyklen zeigen einige Sprünge, besonders Java 9 wurde zweimal verschoben.

Oracle und Sun waren sehr lange konservativ darin, das Bytecodeformat zu ändern, sodass eine ältere JVM im Prinzip Programme einer neuen Java-Version ausführen konnte. Aber gerade in den Versionen Java 7 und Java 8 gab es doch einige Neuerungen, die die Aufwärtskompatibilität brechen; eine JVM der Version 7 kann also keine Programme mehr ausführen, die ein Java 8-Compiler übersetzt hat. Da einige Teile aus den Java 11-Bibliotheken entfernt wurden, ist auch dadurch die Abwärtskompatibilität eingeschränkt.

Feature-Release vs. zeitorientiertes Release

20 Jahre lang bestimmten Features die Freigabe von neuen Java-Versionen; die Entwickler setzten bestimmte Neuerungen auf die Wunschliste, und wenn alle Features realisiert und getestet waren, erfolgte die allgemeine Verfügbarkeit (eng. general availability, kurz GA). Hauptproblem dieses Feature-basierten Vorgehensmodells waren die Verzögerungen, die mit Problemen bei der Implementierung einhergingen. Vieldiskutiert war das Java 9-Release, weil es unbedingt ein Modulsystem enthalten sollte.

Die Antwort auf diese Probleme, und der Wusch der Java-Community nach häufigeren Releases, beantwortet Oracle mit der „JEP 322: Time-Based Release Versioning“[2]. Vier Releases sind im Jahr geplant:

• Im März und September erscheinen Haupt-Releases, wie Java 10, Java 11.
• Updates erscheinen einen Monat nach einem Haupt-Release und dann im Abstand von drei Monaten. Im April und Juli erscheinen folglich Updates 10.0.1 und 10.0.2. Für Java 11 sind das Oktober 2018 und Januar 2019.

Anders gesagt: Im Halbjahresrhythmus gibt es Updates, die es Oracle erlauben, in der schnelllebigen IT-Zeit die die Sprache und Bibliotheken weiter zu entwickeln und neue Spracheigenschaften zu integrieren. Kommt es zu Verzögerungen, hält das nicht gleich das ganze Release auf. Java 10 war im März 2018 das erste Release nach diesem Zeitplan, Java 11 folgte im September 2018.

Codenamen, Namensänderungen und Vendor-Versionsnummer

Die ersten Java-Versionen waren Java 1.0, Java 1.1, usw. Mit Java 5 entfiel das Präfix »1.« in der Versionskennung des Produkts, sodass es einfach nur Java 5, Java 6, etc. hieß; in den Entwicklerversionen blieb die Schreibweise mit der »1.« aber weiterhin bis Java 9 gültig.[3] In Java 10 kommt durch das „Time-Based Release Versioning“[4] eine Vendor-Kennung hinzu, sodass alternativ zu Java 11 auch von 18.9 die Sprache ist; gut lässt sich daran die Jahreszahl und der Monat vom Release ablesen.

[1] Die Seite http://tutego.de/go/migratingtojava5 zeigt auf, wie Walmart der Umstieg auf Java 5 gelang – relativ problemlos: »[…] the overall feeling is that a migration to Java 1.5 in a production environment can be a mostly painless exercise.«

[2]     http://openjdk.java.net/jeps/322

[3] Siehe dazu http://docs.oracle.com/javase/1.5.0/docs/relnotes/version-5.0.html.

[4] http://openjdk.java.net/jeps/322

Vor 20 Jahren war ein großer Pluspunkt die Einfachheit im Vergleich zum Vorgänger C++ und das Fehlen von »gefährlichen« syntaktischen Konstrukten. So schrieb einer der Sprachväter, James Gosling – der nach der Übernahme von Sun durch Oracle das Unternehmen verließ –, schon 1997:

»Java ist eine Arbeitssprache. Sie ist nicht das Produkt einer Doktorarbeit, sondern eine Sprache für einen Job. Java fühlt sich für viele Programmierer sehr vertraut an, denn ich tendiere stark dazu, Dinge zu bevorzugen, die schon oft verwendet wurden, statt Dingen, die eher wie eine gute Idee klangen.«[1]

Der Wunsch nach einer einfachen Sprache besteht bis heute, allerdings ist in den letzten 20 Jahren viel passiert, und Java deutlich komplexer geworden. Bedeutende Sprachänderungen gab es in Java 5 (also etwa zehn Jahre nach der Einführung von Java) und in Java 8. Das Modulsystem in Java 9 bringt ebenfalls neue Herausforderung.

Bei der Dreifaltigkeit der Java-Plattform – 1. Java als Programmiersprache, 2. den Standardbibliotheken und 3. der JVM als Laufzeitumgebung – lässt sich erkennen, dass es große Bewegung bei den unterschiedlichen Programmiersprachen auf der Java-Laufzeitumgebung gibt. Es zeichnet sich ab, dass Java-Entwickler weiterhin in Java entwickeln werden, aber eine zweite Programmiersprache auf der JVM zusätzlich nutzen. Das kann JavaScript, Groovy, Kotlin, Scala, Jython, JRuby oder eine andere JVM-Sprache sein. Dadurch, dass die alternativen Programmiersprachen auf der JVM aufsetzen, können sie alle Java-Bibliotheken nutzen und daher Java als Programmiersprache in einigen Bereichen ablösen. Dass die alternativen Sprachen auf die üblichen Standardbibliotheken zurückgreifen, funktioniert reibungslos, allerdings ist der umgekehrte Weg, dass etwa Scala-Bibliotheken aus Jython heraus genutzt werden, (noch) nicht standardisiert. Bei der .NET-Plattform klappt das besser, und hier ist es wirklich egal, ob C# oder VB.NET Klassen deklariert oder nutzt.

Als die Übernahme von Sun vor der Tür stand, zeigte Oracle sich sehr engagiert gegenüber den Sun-Technologien. Nach der Übername 2010 wandelt sich das Bild etwas, und Oracle hat eher für negative Schlagzeilen gesorgt, etwa als es die Unterstützung für OpenSolaris eingestellt hat, seitdem es MySQL zurückfährt und als Gefahr für die eigene Datenbank sieht und weil es OpenOffice erst spät an Apache übergeben hat (als sich LibreOffice schon verselbstständigt hatte). Auch was die Informationspolitik und Unterstützung von Usergroups angeht, verhält sich Oracle ganz anders als Sun. Durch die Klage gegen Google wegen Urheberrechtsverletzungen in Android machte sich Oracle auch keine Freunde. Android gilt als Beweis, dass Java auf dem Client tatsächlich erfolgreich ist. Anlässlich der Sicherheitslücken in Java machte das Unternehmen ebenfalls keine gute Figur, insgesamt dürfte auf einer Bewertung zu finden sein: »Oracle hat sich bemüht, den Anforderungen gerecht zu werden.«

Fast 10 Jahre nach der Übernahm gibt es neue radikale Änderungen. Erstmals entfernte Oracle Teile der Java SE-Bibliothek, wie CORBA-Unterstützung, JAXB, JAX-RS (Web-Services), Applets, Java Web Start und JavaFX, auch die JavaScript-Engine soll verschwinden. Damit ist die bisher heilige Abwärtskompatibilität aufgegeben – Java 11 kann nicht in jedem Fall ältere Java-Software ausführen. Ein weiter Schock ist die Kommerzialisierung. Oracle bringt mit dem OracleJDK alle halbe Jahre ein neues Release heraus, was jedoch ab Java 11 nur für „development, testing, prototyping or demonstrating purposes“ genutzt werden darf, also nicht mehr kommerziell; für eine kommerzielle Nutzung fallen Gebühren an.[2] Da das OracleJDK allerdings nur eine Java SE-Implementierung von vielen ist, gibt es gute Alternativen, wie das OpenJDK.

[1] Im Original: »Java is a blue collar language. It’s not PhD thesis material but a language for a job. Java feels very familiar to many different programmers because I had a very strong tendency to prefer things that had been used a lot over things that just sounded like a good idea.« (http://www.computer.org/portal/web/csdl/doi/10.1109/2.587548)

[2] http://www.oracle.com/technetwork/java/eol-135779.html

Rich Internet Applications (RIA) sind grafisch anspruchsvolle Webanwendungen, die in der Regel Daten aus dem Internet beziehen. Viele Jahre beherrschte Adobe Flash hier fast zu 100 % das Feld, und Microsoft spielte mit Silverlight zeitweilig mit. Auch Oracle wollte aus strategischen Gründen das Feld nicht den Mitbewerbern überlassen. Als sich abzeichnete, dass Applets zu unflexibel für komplexe GUI-Anwendungen sind, veröffentlichte Oracle nach längerer interner Projektphase Ende 2008 die JavaFX-Plattform. JavaFX ist ein ganz neuer GUI-Stack und komplett von Swing und AWT entkoppelt.

In der ersten JavaFX-Version gehörte die Programmiersprache JavaFX Script mit dazu, doch ab Version JavaFX 2 hat Oracle die Richtung geändert: JavaFX ist nun eine pure Java-Bibliothek, und JavaFX Script verschwand. Mit Skriptsprachen auf der Java-VM ist jedoch ein vergleichbares »Feeling« gewährleistet.

Eine Zeit lang sah es so aus, als ob JavaFX den GUI-Stack AWT/Swing beerben könnte. Swing ist eine GUI-Bibliothek, die schon seit Java 1.2 (1998) zum Standard gehört, doch seit 10 Jahren keinen nennenswerten Features mehr bekommen hat, wohl aber regelmäßig Bugs gefixt werden. Nach anfänglichem Hype um JavaFX hat Oracle viele Entwickler abgezogen und auch JavaFX auf das Abstellgleis gestellt. Für Oracle spielen Desktop-Technologien keine Rolle mehr, weshalb sich Oracle 2018 ganz von JavaFX verabschiedet hat: JavaFX wurde aus der Java SE entfernt und ist kein Teil mehr von Java 11. Oracle hat JavaFX in das OpenJFX (https://wiki.openjdk.java.net/display/OpenJFX/Main) überführt, wo es als Open-Source-Projekt weiterentwickelt wird – ein Mirror ist https://github.com/teamfx. Für JavaFX-Fans ist das eher ein Vorteil als Nachteil, denn eine Entkopplung ermöglicht eine flexiblere Weiterentwicklung; OpenJFX ist dann ein Modul wie jedes andere auch.

Es ist nicht untertrieben, dem Web eine Schlüsselposition bei der Verbreitung von Java zuzuschreiben. Populär wurde Java Mitte der 1990er Jahre durch Applets – Java-Programme, die ein Browser ausführt. Eine HTML-Datei referenzierte das Applet, es bekam auf der Webseite einen Platz zugewiesen, der Browser holte sich eigenständig die Klassendateien und Ressourcen über das Netz und führte sie in der JVM aus.

Im Laufe ging die Bedeutung für Java-Applets immer weiter zurück, und das lag an der Sprache, die ebenfalls 1995 erschien: JavaScript. Java-Applets brachten erstmals Dynamik und bewegte Grafik in die bis dahin statischen Webseiten, doch als dann die Web-Standards CSS (1996) und SVG auftauchen (2001), setzen immer mehr Web-Entwickler eine Kombination von JavaScript mit diesen Standards. Denn Java-Applets haben, genauso wie Flash oder  Silverlight alle ein Problem: Sie benötigen ein Browser-Plugin. Das macht sie unattraktiv für Unternehmen, da im Internet kein Kunde ausgeschlossen werden soll. Früher, als die Webstandards noch nicht so weit entwickelt waren, brachten Flash und Silverlight Dynamik auf die Webseite, doch heute sind aufwändige Webanwendungen mit JavaScript und HTML 5/CSS3 realisierbar. Auch Microsoft stoppte bei Silverlight 5 die Entwicklung und bevorzugt nun Lösungen auf der Basis von JavaScript + HTML 5 + CSS3, insbesondere für mobile Endgeräte, da den Redmondern klar ist, dass es nie Silverlight auf dem iPhone oder Android geben wird.[1] Adobe selbst beginnt mit Konvertern von Flash nach HTML 5/CSS3/JavaScript und zeigt damit auch die Zukunft auf.

Es ist lange her, dass die frühen Browser Netscape und Internet Explorer eine JVM integrierten – irgendwann haben die Hersteller die Java-Laufzeitumgebung entfernt. Eine Zeit lang lieferte Oracle das Java Plug-in aus, um die eigene JVM in den Browser zu integrierten. Moderne Browser unterstützen das Java Plug-in jedoch nicht mehr. Wegen fehlender Unterstützung in den Browsern – und den gute Web-Standards – markierte Oracle in Java 9 Applets als veraltet und entfernte sie komplett in Java 10. Java Web Start war eine Alternative ähnlich den Applets, mit der sich Programme aus dem Internet laden lassen, allerdings ist auch Java Web Start nicht mehr Teil von Java 11.

[1] Mit https://xamarin.com/platform gibt es interessante Ansätze.