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