© godrick, 123RF.com

Ende Juli gaben die Entwickler die siebte Version von Java frei. Viele kleine Änderungen ebnen den Programmierern den Weg, die nun die erste offizielle Java-Version mit offenen Quellen erhalten. Doch der Brückenschlag war alles andere als einfach, ein Plan B war nötig und manches kommt erst mit Version 8.

Auf den ersten Blick ist Mark Reinhold nur zu beneiden. Seit Java 1.1 ist er an der Entwicklung der Kernkomponenten der Sprache beteiligt und mittlerweile Chef der Java-Entwicklung. Sein jüngster Erfolg ist die Veröffentlichung der von vielen Programmierern heiß ersehnten Java-Version 7 im Juli 2011 [1].

Das ist kein Randereignis in der IT-Welt, ist das plattformunabhängige Java doch seit Jahren eine der erfolgreichsten Sprachen und erfreut sich einer großen und aktiven Entwicklergemeinde. Damit dies so bleibt, bietet die neue Version Vereinfachungen für Developer und verleiht Oberflächen ein neues Aussehen.

Open Source?

Dabei hatte eine der ersten für die neue Version nötigen Entscheidungen gar nichts mit Technik zu tun: Das von Sun entwickelte Java ist zwar seit jeher kostenlos für Linux und andere Plattformen verfügbar, der Großteil der Quellen blieb jedoch trotz heftiger Kritik fest unter Verschluss. Ab Mitte 2006 gab sich Sun zunehmend offener und stellte die Sourcen unter die GPL. Damit konnte erstmals jeder Interessierte Einblick nehmen und Änderungen vornehmen.

Offene Quellen sind aber nur die halbe Miete, daher richtete Sun mit dem Java Community Process auch ein Regelwerk für die Koordinierung der Weiterentwicklung ein. In dem Steuerungskomitee nahmen Branchengrößen wie IBM und SAP, aber auch Red Hat und die Apache Foundation als Vertreter der Open-Source-Gemeinde Platz.

Dieser Brückenschlag stellte für Suns Kronjuwel einen radikalen Wechsel in Richtung freie Software dar. Lohn der Mühe ist jetzt Java 7, das erstmals als Quelltext [2] und fertig kompiliert [3] bereitsteht. Die Version enthält Verbesserungen in allen drei Bereichen, die die Entwicklung von Java-Programmen vereinfachen: Sprache, Bibliotheken und Laufzeitumgebung.

Einfachere Sprache

Am auffälligsten sind die Erweiterungen der Sprache selbst. Viele Änderungen entstammen dem Projekt Coin [4] unter der Leitung von Joe Darcy. Dessen Ziel sind kleine Änderungen der Java-Syntax, die den Quelltext besser lesbar und schlanker machen sollen.

Im Vergleich zu anderen Sprachen ist Java als recht geschwätzig verschrien, gerade die mit Java 5 eingeführten Typ-sicheren Container (Generics) sind gefürchtet: Typdeklarationen muss der Programmierer sowohl bei der Variablendeklaration als auch bei der Erzeugung eines Containers angeben. Diese Arbeit übernimmt nun der Compiler, er ersetzt die neue Schreibweise »<>« (Diamond-Operator) automatisch durch den richtigen Typ (Listing 1, Zeile 4).

01 // JDK 6
02 Map<String, List<Integer>> altName2msn = new HashMap<String, List<Integer>>();
03 // JDK 7, Diamond Operator
04 Map<String, List<Integer>> coinName2msn = new HashMap<>();
05
06 // JDK 6
07 OutputStream fos = null;
08 try {
09     fos = new FileOutputStream("ausgabe.txt");
10     fos.write(42);
11 } catch (IOException exp) {
12     // ...
13 } finally {
14     try {
15         if (fos != null) {
16             fos.close();
17         }
18     } catch (IOException exp) {
19         // ...
20     }
21 }
22
23
24 // JDK 7, Try with Resource and multiple catch
25 try (OutputStream out = new FileOutputStream("ausgabe.txt")) {
26     out.write(42);
27 } catch (ArithmeticException | IOException exp) {
28     // ...
29 }
30
31 // JDK 6
32 long SOURCE_ENTITY_TYPE_MASK = Long.parseLong("10000000" + //
33         "00000000" + //
34         "00000000" + //
35         "10000000", 2);
36 // JDK 7
37 long coin = 0b10000000_00000000_00000000_10000000L;
38
39 // JDK 7, Datei kopieren
40 File src = new File("eingabe.txt");
41 File dest = new File("ausgabe.txt");
42 Files.copy(src.toPath(), dest.toPath(), StandardCopyOption.REPLACE_EXISTING);

Die korrekte Behandlung externer Abhängigkeiten wie Dateien oder Datenbanken ist in jeder Sprache aufwändig und bietet viel Raum für potenzielle Fehler, die zur Laufzeit sauber abzufangen sind. Mit dem neuen Konstrukt »try-with-resources« muss der Programmierer dies nicht mehr explizit angeben. Das verkleinert den Code beispielsweise bei Problemen, wie sie durch offene Handles entstehen. Das erweiterte Try-Statement enthält nun das Öffnen der Ressourcen, sie werden beim Verlassen des Try-Blocks auf jeden Fall geschlossen, auch ohne dass der Programmierer dies explizit angibt.

In den Genuss dieser einfachen Schreibweise (Listing 1, Zeile 25) kommen neben dem einfachen File-I/O auch Datenbank-Verbindungen und -Statements. Das Catch-Statement haben die Java-Entwickler bei dieser Gelegenheit ebenfalls verbessert, es kann nun mehrere Ausnahmen auf einmal fangen, statt für jeden Fehlertyp ein eigenes Catch-Statement zu verlangen (Listing 1, Zeile 27).

Aber auch anderswo finden sich Spuren der Detailpflege: Das Switch-Statement schwimmt sich ein Stück weit von seinem C-Vorfahren frei. Bisher ließ es sich nur mit Integers und Enumerationen verwenden, nun kann es auch mit String-Konstanten arbeiten. Zahlen im Quelltext dürfen Programmierer mit dem Präfix »0b« wie bei Python oder beim GCC binär schreiben, Unterstriche gliedern sie zur besseren Lesbarkeit auf (Listing 1, Zeile 37).

Neu: Files, SCTP, Nimbus

Die gut 1300 Klassen der Standardbibliotheken lösen bereits in Java 6 so ziemlich jedes Basisproblem. Vor diesem Hintergrund enthält Java 7 nur wenige Änderungen. Am wichtigsten ist die lang ersehnte Erweiterung für den Zugriff auf das Dateisystem. Erst mit der neuen Klasse »Files« ist es endlich möglich, eigentlich triviale Dinge wie Dateibesitzer, Zugriffsrechte oder Links plattformneutral abzufragen und zu ändern. Vorher mussten Entwickler dies selber implementieren und teilweise externe Tools wie »ls« dafür einsetzen.

Die Files-Klasse ist das Schweizer Taschenmesser für vieles, was Java im Bereich Dateisystem immer gefehlt hat. Die Nachfrage dafür scheint groß: Zum Thema “Java-Datei kopieren?” findet sich bei Google fast eine Million Treffer (Listing 1, Zeile 42).

Auch im Netzwerkbereich gibt es Änderungen. Java 7 unterstützt erstmals das Stream Control Transmission Protocol (SCTP, [5]). Es ist ein weiteres Transportprotokoll neben TCP und UDP und ermöglicht unter anderem die parallele Übertragung von mehreren Datenströmen. Darüber hinaus enthält Java 7 die aktuelle Version der JDBC-Bibliothek für Datenbankanbindung und XML-Behandlung (JAXP, JAXB, JAX-WS).

Das Aussehen der Standardoberfläche Swing [6] konnten Entwickler von Anfang an nahezu beliebig ändern, Pluggable-Look-and-Feel-Bibliotheken (PLAF) wie Jgoodies Looks [7] oder Napkin [8] zeigen die ganze Bandbreite von Business bis Krakelei. Leider hat das normalerweise verwendete »plaf.metal« nach wie vor den freundlichen Charme der 90er Jahre. Java 7 enthält mit Nimbus endlich eine Alternative, es passt besser auf einen aktuellen Desktop und ist zudem voll Vektor-basiert. Abbildung 1 zeigt Netbeans als erste voll JDK-7-kompatible Entwicklungsumgebung mit Nimbus.

Abbildung 1: Netbeans 7.0 unterstützt alle neuen Features von Java 7, hier gleich im neuen Nimbus-Look.

Als kleine Weiterentwicklung im GUI-Bereich übernimmt die Jlayer-Klasse auch die ersten Goodies aus den Swing Labs [9]. Sie erlauben es, tief in das Aussehen und Verhalten von Widgets einzugreifen, ohne diese selbst zu ändern. Den in Abbildung 2 gezeigten Text und den Strich zeigt das Widget nur über einem leeren, ungeänderten Eingabefeld an. Den Quelltext dazu gibt’s bei [10].

Abbildung 2: Das Verhalten von Standardwidgets wie des Eingabefelds lässt sich per Jlayer verändern.

Bis 2006 war der Quelltext der Java Virtual Machine (JVM) nur wenigen zugänglich. Das hat sich geändert, der Wiener Student Clemens Eisserer beispielsweise nutzte die Öffnung für sein Xrenderer-Projekt [11]. Er wollte ein neues Java-2D(Swing)-Backend für X11 entwickeln, das die Hardwarebeschleunigung moderner Grafikkarten nutzt. Das Projekt kam so gut an, das es fester Bestandteil von Java 7 wurde. Überhaupt dient die JVM zunehmend nicht nur als Laufzeitumgebung von Java, immer mehr Sprachen setzen auf die bewährte Basis.

Damit erledigen sich gleich zwei Probleme: Die riesige Funktionsauswahl in Java-Bibliotheken steht ohne Neu-Implementierung bereit und beim Nutzer muss keine weitere Laufzeitumgebung installiert werden. Gerade für dynamischere Skriptsprachen war die typsichere JVM jedoch nicht besonders gastfreundlich, mit der Invoke-Dynamics-Erweiterung [12] gelingt der Brückenschlag wesentlich eleganter und schneller.

Plan B: Von Java 6 zur 8

Insgesamt enthält Java 7 also eine ganze Reihe begrüßenswerter Änderungen. Doch der Weg von Version 6 zu 7 war alles andere als geradlinig. Insofern ist Mark Reinhold um seinen Job vielleicht doch nicht zu beneiden. Das Java-7-Projekt war mit großem Schwung gestartet, ersetzte einige von Sun nur lizenzierte Teile der JVM relativ schnell durch Open-Source-Komponenten und machte die Versprechung eines quelloffenen Java wahr. Auf dessen Basis entstand Open JDK 6, das aktuell Teil der meisten Linux-Distributionen ist.

Auf der Wunschliste für Java 7 standen anfangs aber neben den jetzt umgesetzten Features noch viele mehr, etwa die Modularisierung der riesigen Standardbibliothek (Projekt Jigsaw, [13]) oder moderne Features wie Closures. Die Freigabe war für Februar 2010 geplant, doch war das Projekt zu diesem Zeitpunkt noch lange nicht reif.

Gründe gab es reichlich. Da waren zum einen die Finanzprobleme beim Hauptträger der Entwicklung. Trotz attraktiver Software (Java, Netbeans [14], Glassfish, Solaris, Open Office) gelang es Sun in den letzten Jahren nicht mehr, eine sinnvolle Rendite zu erzielen. Die Geschäftspolitik ließ eine klare Linie vermissen, Projekte wie Java FX [14] startete Sun mit viel Getöse – und ließ sie genauso schnell fallen. 2009 übernahm dann Oracle das Unternehmen.

Der neue Eigentümer war bis dato noch nie als Akteur im Open-Source-Bereich aufgefallen und verhielt sich nach der Übernahme recht ungeschickt. So kündigte eine ganze Reihe hochkarätiger Entwickler, mit zu den ersten gehörte der jetzt bei Google tätige Java-Vater James Gosling. Auch in der Gremienarbeit gab es ständig Differenzen mit den Partnern: So verließ die Apache Foundation Ende 2010 das Java-Steuerungskomitee im Streit.

Neben diesen firmenpolitischen Problemen schleppte sich auch die Entwicklung selbst dahin. Im August 2010 zog Mark Reinhold die Reißleine und veröffentliche seinen “Plan B” für Java 7. Der reduzierte die Anzahl der Neuerungen auf den jetzigen Stand und sah die Auslieferung für Juli 2011 vor. Die restlichen Features sind nun für die Java-Version 8 im nächsten Jahr geplant. So ist die Anzahl der Änderungen – jedenfalls für eine ungerade Java-Version – vergleichsweise gering ausgefallen.

Trotzdem begrüßen die meisten Java-Entwickler die Entscheidung sehr, und mit dem Plan B übernahm Mark Reinhold wieder die Herrschaft über den Terminplan. Wie es nach Java 8 weitergehen soll, ist inzwischen ein viel diskutiertes Thema. Auf der JVM laufende Alternativsprachen wie Red Hats Ceylon [15] zeigen, in welche Richtung der Zug fahren könnte. Vielleicht wagen die Entwickler auch endlich den großen Sprung und entrümpeln Java – auch auf Kosten der Rückwärtskompatibilität?

Politik, Politik

Politisch muss Oracle bei Java und den Werkzeugen im Umfeld (Hudson [16], Netbeans) der Spagat zwischen Rendite-Erwartung und einem fairen Umgang mit der Open-Source-Szene gelingen. Sonst schauen sich Entwickler mittelfristig nach Alternativen um, auch wenn sich Mono aktuell nicht gerade anbietet [17].

Im Zuge der Sun-Übernahme wurde viel Porzellan zerschlagen, langsam scheint sich Oracle aber offener zu geben. So stellte Patrick Curran mit JCP.next [18] eine neue Version des Java Community Process vor. Der regelt die Arbeit der Fachkomitees, die die Entwicklung von Bibliotheken oder der Sprache selbst führen. Ziel der Vorschläge sind erhöhte Transparenz, verbesserte Teilhabe sowie schnellere Entscheidungsfindung. Das tatsächlich umzusetzen und vor allem der Wiedereinzug der Apache Foundation wäre der Zukunft von Java mehr als förderlich. (mfe/mhu)