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.

Im Internet hat JSON das XML-Format zwecks Objektübertragung zwischen Server und Browser fast vollständig verdrängt. Das liegt daran, dass ein Browser JSON-Strings direkt in JavaScript-Objekte konvertieren kann, XML-Dokumente aber erst aufwändiger verarbeitet werden müssen.

Neben dem Einsatzgebiet im Internet bietet JSON auch ein kompaktes Format, um etwa lokale Konfigurationsdateien zu kodieren.

JSON im Kontext von JavaScript

Nehmen wir folgende Zeile JavaScript-Code, die ein Person-Objekt mit zwei Properties für Name und Alter definiert. Eine Property wird über ein Schlüssel-Wert-Paar beschrieben:

var person = { „name“ : „Michael Jackson“, „age“ : 50 };

Die Definition eines Objekts geschieht in der JSON (JavaScript Object Notation). Als Datentypen unterstützt JSON Zahlen, Wahrheitswerte, Strings, Arrays, null und Objekte – wie unser Beispiel zeigt. Die Deklarationen können geschachtelt sein, um Unterobjekte aufzubauen.

Zum Zugriff auf die JSON-Daten kommt der Punkt zum Einsatz, sodass der Name nach der Auswertung durch person.name zugänglich ist.

Eine Personenbeschreibung wie diese kann in einem String stehen, der von JavaScript zur Laufzeit ausgewertet wird.

var json = ‚person = { „name“ : „Michael Jackson“, „age“ : 50 };‘;

Der Zugriff auf person.name liefert wie vorher den Namen, denn nach der Auswertung mit eval(…) wird JavaScript ein neues Objekt mit person im Kontext anlegen.

JSON ist besonders praktisch, wenn es darum geht, Daten zwischen einem Server und einem Browser mit JavaScript-Interpreter auszutauschen. Denn wenn der String json nicht von Hand mit einem String initialisiert wurde, sondern ein Server die Zeichenkette person = { … }; liefert, haben wir das, was heutzutage in modernen Ajax-Webanwendungen passiert.

Die letzte Frage ist nun, wie elegant der Server Zeichenketten im Datenaustauschformat JSON erzeugt und so Objekte überträgt. Den String per Hand aufzubauen ist eine Lösung, aber es geht besser.

JSON-Verarbeitung mit der Java API for JSON Processing

Zum Verarbeiten von JSON-Dokumenten gibt es in der Java SE keine Standardklassen, sodass sich eine Reihe von Open-Source-Bibliotheken herausgeprägt haben; Jackson (http://tutego.de/go/jackson) gehört zu den populärsten Lösungen. 2013 wurde dann die JSR 353, »Java API for JSON Processing«, verabschiedet, die Teil der Jakarta EE 7 ist, 2014 dann das JSR 374 »Java API for JSON Processing 1.1«.

Wir können die JSON-API in unseren Java SE-Programmen nutzen, müssen dafür aber Java-Archive im Klassenpfad einbinden. Die Referenzimplementierung befindet sich unter https://javaee.github.io/jsonp/. Am einfachsten haben es Maven-Nutzer, sie binden in ihre POM die Abhängigkeiten auf den „Default provider for JSR 374:Java API for Processing JSON“ ein:

<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.json</artifactId>
<version>1.1</version>
</dependency>

Die Implementierung hat eine Abhängigkeit zur JSON-API javax.json:javax.json-api, die wir dann nicht unbedingt selbst in die POM mit aufnehmen müssen.

Aufbau von JSON-Objekten, Formatieren und Parsen

Der Typ JsonObject ist in der API zentral, denn er definiert ein hierarchisches Model mit den Schlüssel-Wert-Paaren eines JSON-Objekts. Um ein JsonObject aufzubauen, können wir über den JsonObjectBuilder gehen, oder wir lassen den Parser JsonReader aus einer String-Repräsentation ein JsonObject erzeugen. Zum formatierten Schreiben in einen Ausgabestrom können wir einen einfachen JsonWriter von der Json-Klasse holen – es geht aber noch einfacher über toString() – oder über die JsonWriterFactory arbeiten, falls wir eine hübsche eingerückte Ausgabe wünschen. Ein Beispiel:

Point p = new Point( 10, 20 );

JsonObjectBuilder objBuilder = Json.createObjectBuilder()
.add( „x“, p.x )
.add( „y“, p.y );
JsonObject jsonObj = objBuilder.build();

System.out.println( jsonObj );  // {„x“:10,“y“:20}

Json.createWriter( System.out ).write( jsonObj ); // {„x“:10,“y“:20}

Map<String, Boolean> config = new HashMap<>();
config.put( JsonGenerator.PRETTY_PRINTING, true );
JsonWriterFactory writerFactory = Json.createWriterFactory( config );

StringWriter out = new StringWriter();
writerFactory.createWriter( out ).write( jsonObj );
System.out.println( out );  // {\n    „x“: 10, …

JsonReader reader = Json.createReader( new StringReader( out.toString() ) );
System.out.println( reader.readObject().getInt( „x“ ) ); // 10

Soll der assoziierte Wert ein Array sein, so wird das Array mit Json.createArrayBuilder().add(..).add(..) aufgebaut und gefüllt.

JSON-Streaming API

So wie es für XML eine Pull-API gibt, existiert sie auch für JSON-Dokumente; das ist von Vorteil, wenn die Daten sehr umfangreich sind. Ein Beispiel zeigt das sehr gut:

URL url = new URL( „https://data.cityofnewyork.us/api/views/25th-nujf/rows.json?accessType=DOWNLOAD“ );

try ( JsonParser parser = Json.createParser( url.openStream() ) ) {
while ( parser.hasNext() ) {
switch ( parser.next() ) {
case KEY_NAME:
case VALUE_STRING:
System.out.println( parser.getString() );
break;
case VALUE_NUMBER:
System.out.println( parser.getBigDecimal() );
break;
case VALUE_TRUE:
System.out.println( true );
break;
case VALUE_FALSE:
System.out.println( false );
break;
case VALUE_NULL:
case START_ARRAY:
case END_ARRAY:
case START_OBJECT:
case END_OBJECT:
// Ignore
}
}
}

Zum Schreiben gibt es Vergleichbares, einen JsonGenerator; die API ist selbsterklärend:

JsonGenerator gen = Json.createGenerator( System.out );
gen.writeStartArray();
gen.writeStartObject();
gen.write( „x“, „12“ );
gen.write( „y“, „2“ );
gen.writeEnd();
gen.writeStartObject()
.write( „x“, „99“ )
.write( „x“, „123“ )
.writeEnd();
gen.writeEnd().close();
// [{„x“:“12″,“y“:“2″},{„x“:“99″,“x“:“123″}]

Der JsonGenerator ist AutoCloseable, sodass er gut in einem try-mit-Ressoucen-Block eingesetzt werden kann.

Objekt-JSON-Mapping

Das JSR 353 beschreibt kein automatisches Objekt-JSON-Mapping, wie JAXB das Objekt-XML-Mapping ermöglicht. Das wird im Standard JSR 367, »Java API for JSON Binding (JSON-B)« definiert. Die Website http://json-b.net/ liefert Hintergrundinformationen, die Referenzimplementierung ist Eclipse Yasson.

Um das mit einem Beispiel testen zu können, nehmen wie Yasson in unsere POM mit auf:

<dependency>

<groupId>org.eclipse</groupId>

<artifactId>yasson</artifactId>

<version>1.0.1</version>

</dependency>

Die Dependency selbst hat eine Maven Abhängigkeit auf javax.json.bind:javax.json.bind-api, also der eigentliche API.

Zur Abbildung bauen wir uns ein Beispielobjekt und bringen es in das JSON-Format. Im zweiten Schritt übertragen wir den JSON-String wieder auf das Objekt:

public class JsonbDemo {

public static class EvilLaboratory {

public String from;

public double volume;

public boolean didPayElectricityBill;

public List<String> items;

}

public static void main( String[] args ) {

EvilLaboratory lab1 = new EvilLaboratory();

lab1.from = „Frank“;

lab1.didPayElectricityBill = true;

lab1.volume = 12442.33;

lab1.items = List.of( „corpses“, „animals“ );

 

Jsonb jsonbuilder = JsonbBuilder.create();

String jsonString = jsonbuilder.toJson( lab1 );

System.out.println( jsonString );

 

EvilLaboratory lab2 = jsonbuilder.fromJson( jsonString, EvilLaboratory.class );

System.out.printf( „from=%s, volume=%s, didPayElectricityBill=%s, items=%s“,

lab2.from, lab2.volume, lab2.didPayElectricityBill, lab2.items );

}

}

Eine freie Java-Bibliothek zum Lesen und Schreiben von CSV-Dokumenten ist Apache Commons CSV (https://commons.apache.org/proper/commons-csv/). Sie verwaltet unterschiedliche CSV-Formate wie Microsoft Excel, RFC 4180.

Auf der Webseite gibt es einen Download-Link für das Java-Archiv, doch am einfachsten ist die Einbindung über die Maven-POM-Datei – wir fügen folgende Abhängigkeit hinzu:

<dependency>

<groupId>org.apache.commons</groupId>

<artifactId>commons-csv</artifactId>

<version>1.5</version>

</dependency>

Über die Abhängigkeit bekommen wir neue Typen im Paket org.apache.commons.csv. Mit dem CSVPrinter lassen sich CSV-Dokumente korrekt erzeugen, und er behandelt auch Fluchtsymbole korrekt. Erzeugen wir ein CSV-Dokument im Speicher:

StringBuilder appendable = new StringBuilder();

CSVFormat csvFormat = CSVFormat.EXCEL.withHeader( „DisplayName“, „ISO3Language“ );

try ( CSVPrinter csvPrinter = new CSVPrinter( appendable, csvFormat ) ) {

for ( Locale l : Arrays.copyOf( Locale.getAvailableLocales(), 5 ) )

csvPrinter.printRecord( l.getDisplayName(), l.getISO3Language() );

}

Starten wir das Programm erscheint auf der Konsole:

DisplayName,ISO3Language

„“,

Norwegisch Nynorsk,nno

Arabisch (Jordanien),ara

Bulgarisch,bul

Kabuverdianu,kea

Lesen wir das Dokument wieder ein und greifen dazu auf die Klasse CSVParser zurück. Es gibt zwei Ansätze:

1. Da CSVParser ein Iterable<CSVRecord> ist, können wir direkt die Zeilen mit dem erweiterten for Das bietet sich für größere Datenmengen an.
2. Ist die Anzahl der Daten überschaubar, liefert getRecords() eine gefüllte util.List<CSVRecord> mit alle Zeilen. Das kann praktisch sein, denn eine List hat eine stream()-Methode, sodass die Zeilen praktisch als Stream<CSVRecord> weiterverarbeitet werden können.

Zum Programm:

try ( StringReader reader = new StringReader( appendable.toString() );

CSVParser csvParser = new CSVParser( reader,

CSVFormat.EXCEL.withFirstRecordAsHeader() ) ) {

for ( CSVRecord csvRecord : csvParser )

System.out.printf( „Record=%d – %s, %s%n“,

csvRecord.getRecordNumber(),

csvRecord.get( 0 ), csvRecord.get( 1 ) );

}

Die Ausgabe ist:

Record=1 – ,

Record=2 – Norwegisch Nynorsk, nno

Record=3 – Arabisch (Jordanien), ara

Record=4 – Bulgarisch, bul

Record=5 – Kabuverdianu, kea

In der Anfangszeit verursachte Microsoft einigen Wirbel um Java. Mit Visual J++ (gesprochen »Jay Plus Plus«) bot Microsoft schon früh einen eigenen Java-Compiler (als Teil des Microsoft Development Kits) und mit der Microsoft Java Virtual Machine (MSJVM) eine eigene schnelle Laufzeitumgebung. Das Problem war nur, dass Dinge wie RMI und JNI absichtlich fehlten[1] – JNI wurde 1998 nachgereicht. Entgegen allen Standards führte der J++-Compiler neue Schlüsselwörter wie multicast und delegate ein. Außerdem fügte Microsoft einige neue Methoden und Eigenschaften hinzu, zum Beispiel J/Direct, um der plattformunabhängigen Programmiersprache den Windows-Stempel zu verpassen. Mit J/Direct konnten Programmierer aus Java heraus direkt auf Funktionen der Win32-API zugreifen und damit reine Windows-Programme in Java programmieren. Durch Integration von DirectX sollte die Internet-Programmiersprache Java multimediafähig gemacht werden. Das führte natürlich zu dem Problem, dass Applikationen, die mit J++ erstellt wurden, nicht zwangsläufig auf anderen Plattformen liefen. Sun klagte gegen Microsoft.

Da es Sun in der Vergangenheit finanziell nicht besonders gut ging, pumpte Microsoft im April 2004 satte 1,6 Milliarden US-Dollar in die Firma. Microsoft erkaufte sich damit das Ende der Kartellprobleme und Patentstreitigkeiten. Dass es bis zu dieser Einigung nicht einfach gewesen war, zeigen Aussagen von Microsoft-Projektleiter Ben Slivka über das JDK bzw. die Java Foundation Classes, man müsse sie »bei jeder sich bietenden Gelegenheit anpissen« (»pissing on at every opportunity«).[2]

Im Januar 2004 beendete Microsoft die Arbeit an J++, denn die Energie floss in das .NET-Framework und die .NET-Sprachen. Am Anfang gab es mit J# eine Java-Version, die Java-Programme auf der Microsoft .NET-Laufzeitumgebung CLR ausführt, doch Anfang 2007 wurde auch J# eingestellt. Das freie IKVM.NET (http://www.ikvm.net) ist eine JVM für .NET und verfügt über einen Übersetzer von Java-Bytecode nach .NET-Bytecode, was es möglich macht, Java-Programme unter .NET zu nutzen. Das ist praktisch, denn für Java gibt es eine riesige Anzahl von Programmen, die somit auch für .NET-Entwickler zugänglich sind. Bedauerlicherweise wird das Projekt nicht weiterentwickelt.

Microsoft hat sich lange Zeit aus der Java-Entwicklung nahezu vollständig zurückgezogen. Es waren eher überschaubare Projekte wie der Microsoft JDBC Driver for SQL Server. Das Verhältnis ist heute auch deutlich entspannter, und Microsoft geht wieder einen Schritt auf Java zu. Zu erkennen ist das am Beitritt in die Jakarta EE Working Group und an der Unterstützung von Java-Applikationen in der Windows Cloud Azure.[3] Vielleicht gratuliert Microsoft irgendwann einmal Oracle, wie es auch Linux zum 20. Geburtstag gratuliert hat.[4]

[1] http://www.microsoft.com/presspass/legal/charles.mspx

[2] Würden wir nicht gerade im westlichen Kulturkreis leben, wäre diese Geste auch nicht zwangsläufig unappetitlich. Im alten Mesopotamien steht »pissing on« für »anbeten«. Da jedoch die E‐Mail nicht aus dem Zweistromland kam, bleibt die wahre Bedeutung wohl unserer Fantasie überlassen.

[3] https://azure.microsoft.com/de-de/develop/java/

[4] http://www.youtube.com/watch?v=ZA2kqAIOoZM