Die Freigabe der Version 7 von Java ist für Mitte 2011 angekündigt.  Wir wollen in diesem Beitrag einen Überblick über die zu erwartenden Neuerungen geben und uns einige der neuen Sprachmittel und JDK-Ergänzungen in nachfolgenden Beiträge genauer ansehen.

Die Version 7 von Java hat lange auf sich warten lassen.  Das liegt unter anderem daran, dass im Januar 2010 die Firma Sun Microsystems vom Software-Konzern Oracle übernommen wurde und damit die Verantwortung für Java und den JDK an Oracle übergegangen ist.  Wie vermutlich jede Firmenübernahme führte es Neuorientierungen, Umorganisationen und allerlei strategischen und organisatorischen Neuausrichtungen, die in diesem Falle die Freigabe der Version 7 von Java beeinflusst und verzögert haben.

Aber auch schon vor dieser Firmenübernahme war Java 7 in keinem überzeugenden Zustand.  Der Community Process (JCP), in dem bis dahin die wesentlichen Weiterentwicklungen von Java besprochen, spezifiziert und verabschiedet worden waren, hatte sich seltsam aufgelöst. Das dürfte wesentlich an den Streitigkeiten zwischen der Apache Software Foundation und Sun Microsystems im Zusammenhang mit dem Apache Harmony JDK gelegen haben.  Aber auch verschiedene technische Themen waren extrem umstritten in der Java Community  - Closures/Lambdas und  die Modularisierung gehören zu diesen Streitpunkten.  Die Meinungsverschiedenheiten hatten dazu geführt, dass es zwar Implementierungen für einige Neuerungen gab, aber keinerlei Konsens und auch keine Spezifikation dessen, was implementiert worden war.  Das Ergebnis war ein JDK 7, nämlich der OpenJDK, zu dem Sun Microsystems die maßgeblichen Beiträge geleistet hat.  Aber es gab kein Java 7, also keine Festlegung dessen, was eigentlich die Version 7 von Java ausmacht.  Interessanterweise gab es aber einen (noch von Sun Microsystems veröffentlichten) Meilensteinplan, in dem die Freigabe von Java 7 für den 9. September 2010 angekündigt war.  Genau an diesem Stichtag sah sich Oracle dann veranlasst zu verkünden, dass es leider zu diesem Zeitpunkt keine Freigabe geben werde.   Eine wirkliche Überraschung war es nicht, denn wesentliche Teile der geplanten Features waren weder spezifiziert noch implementiert und getestet.

Der neue Freigabeplan vom September 2010 sieht nun eine Teilung des ursprünglich für Java 7 geplanten Umfangs in eine Version 7 von Java "Mitte 2011" und eine Version 8 von Java "Ende 2012" vor.  Seit dem November 2010 gibt es auch vier JSRs (Java Specification Requests), die die Neuerungen in Java 7 und 8 beschreiben (siehe /JSRQ/). In diesem und den nächsten Beiträgen werden wir anschauen, was es Neues geben wird.  Hier ist eine Übersicht über die wesentlichen Neuerungen; die vollständige Liste ist unter /FEAT/ zu finden.
 

JDK 7 (Mitte 2011)
	JSR 336	Java SE 7 Release Contents
lang	JSR 334	Small language enhancements ("Project Coin")
vm	JSR 292	Support for dynamically-typed languages ("InvokeDynamic")
core	---	Concurrency and collections updates ("Fork-Join" bzw. "jsr166y")
i18n	---	Unicode 6.0
	---	Locale enhancement
	---	Separate user locale and user-interface locale
ionet	JSR 203	More new I/O APIs for the Java platform ("NIO.2")
	---	NIO.2 filesystem provider for zip/jar archives
	---	SCTP (Stream Control Transmission Protocol)
	---	SDP (Sockets Direct Protocol)
	---	Use the Windows Vista IPv6 stack
	---	TLS 1.2

 

JDK 8 (Ende 2012 oder später)
	JSR 337	Java SE 8 Release Contents
vm	JSR 294	Language and VM support for modular programming
	---	A module system for modularizing the JDK ("Project Jigsaw")
lang	JSR 308	Annotations on Java types
	---	Language support for collections
	JSR 335	Lambda expressions, formerly known as "closures", and defender methods ("Project Lambda")
core	---	Concurrency and collections updates that depend on lambdas ("Parallel Arrays" bzw.  "extra166y")

Worum geht es dabei?
 

Project Coin

In den JDK geschafft haben es folgende Vorschläge:

• Strings in switch-Anweisungen
• Verbesserte Schreibweisen für numerische Literale
• Vereinfachungen beim Aufruf von Methoden mit variabler Argumentenliste
• Verbesserte Type Inference für Konstruktoren generischer Typen ("diamond operator")
• Verbessertes Exception Handling
• Automatic Resource Management
• Sprachunterstützung für Collections  (Java 8)

Lediglich der Diamond-Operator hat das Potenzial, noch einmal substantiell umgekrempelt zu werden.  Er setzt auf die Type Inference Algorithmen des Compilers auf.  Diese könnten sich im Zusammenhang mit "Project Lambda" ändern.  Project Lambda ist erst für Java 8 vorgesehen; die Spezifikation ist noch nicht fertig; heute kann niemand absehen, wie die Lambdas am Ende aussehen werden und welche Rückwirkungen ihre Implementierung auf den Diamond-Operator haben werden.

Die Sprachunterstützung für Collections ist noch nicht implementiert und deshalb nicht für Java 7 vorgesehen, sondern gleich auf Java 8 verschoben worden.  Auch hier ist zu erwarten, dass die später frei gegebene Implementierung von den heutigen Vorschlägen abweichen wird.

Die "Coin"-Features werden wir uns in den nächsten beiden Beiträgen genauer ansehen.
 

InvokeDynamic

All diese Bytecode-Instruktionen sind angelegt für eine statisch geprüfte Sprache wie Java, bei der der Typ jedes Objekts und die gesamte Signatur jeder Methode bereits zur Übersetzungszeit feststeht.  Mittlerweile gibt es aber zahlreiche Sprachen auf der Java Virtual Machine, die dynamisch geprüft werden und in denen Methoden eben keine zur Übersetzungszeit festgelegte Signatur haben.  Für die Implementierung von dynamischen Sprachen auf der JVM waren deshalb zahlreiche Klimmzüge nötig, um die Methodenaufrufe zu bewerkstelligen.  Die neue ByteCode-Instruktion invokedynamic löst diese Probleme.

Java-Entwickler werden in Java 7 noch nicht mit invokedynamic nicht in Berührung kommen, weil der Java-Compiler diese Instruktion bislang nicht verwendet.  Deshalb wollen wir invokedynamic an dieser Stelle nicht näher betrachten.  Die neue ByteCode-Instruktion wird jedoch für die Implementierung der für Java 8 vorgesehenen Lambdas benutzt werden und dann auch für Java-Programme von Bedeutung sein.
 

Concurrency Utilities

Die wesentliche Neuerung für Java 7 ist ein Framework für die Parallelisierung von rekursiven Aufgaben, Fork/Join Framework genannt.  Dabei handelt es sich um einen speziellen Thread-Pool für Tasks, die sich rekursiv in Subtasks zerlegen, diese Subtasks starten, auf die Teilergebnisse warten und daraus ein Gesamtergebnis produzieren.  Da solche Aufgaben voneinander abhängen - jede Task wartet auf das Ergebnis ihrer Subtasks – ist der herkömmliche, bereits seit Java 5  im JDK enthaltene Thread-Pool (Klasse ThreadPoolExecutor ) ungeeignet.  Er ist für voneinander unabhängige Tasks gedacht.  Deshalb gibt es mit der Klasse ForkJoinPool eine Thread-Pool-Implementierung, die für das Abarbeiten rekursiver Aufgaben angelegt ist.  Die für Java 8 angekündigten Parallel Arrays werden übrigens auf diesen Fork/Join Framework aufsetzen.

Neben dem Fork/Join Framework kommt mit Java 7 die Abstraktionen Phaser zum Package java.util.concurrent hinzu.  Der Phaser ist eine flexiblere Variante der seit Java 5 existierenden CyclicBarrier . Während sich an einer CyclicBarrier eine fixe Anzahl von Threads trifft und aufeinander wartet, erlaubt der Phaser eine variable Anzahl von beteiligten Parteien.

Eine weitere Neuerung bei den Concurrency Utilities ist die TransferQueue . Dabei handelt es sich um eine Kombination aus einer normalen BlockingQueue und einer SynchronousQueue .  Bei Bedarf kann der Producer warten, bis ein Consumer das neue Element abholt (wie bei der SynchronousQueue ); alternativ kann er das Element einfach in die Queue legen, ohne auf einen Abholer zu warten (wie bei der normalen BlockingQueue ).
 

Internationalisierung

• Unicode 6.0. Java-Programme verwenden den Unicode-Zeichensatz und jeder JDK unterstützt die jeweils aktuelle Version des Unicode-Standards – von Unicode 1.1.5 im JDK 1.0 bis zu Unicode 4.0 in J2SE 5.0 und JDK 6.  Für Java 7 war zunächst die Unterstützung von Unicode 5.1 geplant, aber durch die Verschiebung des Freigabetermins auf Mitte 2011 wird die Unicode-Version 6.0 die aktuelle und damit die vom Java 7 unterstütze Version sein.

• IETF BCP 47 . Die Internet Engineering Task Force (IETF) ist eine Organisation, die sich mit der technischen Weiterentwicklung des Internets befasst.  Unter anderem hat sie im Jahr 1995 im RFC 1766 (RFC = Request for Comments) die Kürzel für die Identifikation von Sprachbereichen wie z.B. "de" für Deutsch und "de-AT" für Deutsch österreichischer Prägung festgelegt.  Diese Sprach-Tags werden z.B. in der Klasse java.util.Locale verwendet, deren Implementierung noch heute auf den mittlerweile hoffnungslos veralteten RFC-1766-Festlegungen basiert.  Für Java 7 ist geplant, die Klasse java.util.Locale so anzupassen, so dass sie den aktuellen IETF-Standard BCP 47 (BCP = Best Current Practice)  verwendet.  Auch dies ist lediglich eine Anpassung an aktuelle Standards.

• Trennung zwischen User Locale und User Interface Locale . Locales werden von den verschiedenen JDK-Klasse zu unterschiedlichen Zwecken verwendet: einerseits für die Formatierung von kulturabhängige Zahlen, Datums-, Zeit- und Währungsangaben und ähnliches, andererseits für die sprachabhängige Darstellung und Verarbeitungen von Texten, die Anzeige von Benutzeroberflächen und ähnliches.  Hier soll eine Trennung zwischen einer User Locale (oder auch Formatting Locale) und einer User Interface Locale (oder auch Language Locale) vorgenommen werden. Inspiriert ist diese Trennung durch die jüngeren Microsoft Windows-Systeme, wo es eine ähnliche Unterscheidung gibt.

NIO.2

• Neues File System API

Die NIO.2 liefert ein neues, sehr umfangreiches File System API.  Dies ersetzt die bisher eher rudimentäre Funktionalität von java.io.File vollständig und geht weit darüber hinaus.  Bestandteil ist des Weiteren ein System Provider Interface (SPI), das es ermöglicht, eigene File Systeme (und/oder Sichten auf Geräte) so einzubinden, dass sie über das neue File System API zugreifbar sind.  Als Bestandteil von Java 7 wird der System Provider Support für ZIP- und RAR-Archive ausgeliefert.

• Erweiterungen für asynchrone I/O

Der zweite größere Teil der NIO.2 sind Erweiterungen für asynchrone I/O.  Dabei geht es zum einen um ein API für asynchrone I/O, das höher angesetzt ist als das bisherige von java.nio.channels.Selector zur Verfügung gestellte API.  Zum anderen geht es um die Ausweitung der asynchronen I/O auf Multicast Datagams und File I/O.

• Diverse Protokolle und Standards

Daneben gibt es noch diverse kleinere Ergänzungen, bei denen es um die Unterstützung verschiedener Protokolle und Standards geht.
• SCTC . Das Stream Control Transmission Protocol (SCTP) ist ein relativ neues Kommunikationsprotokol, das im TCP/IP-Stack parallel zu TCP und UDP steht (siehe /SCTP/).  Hierfür wird es eine API-Implementierung in Java 7 geben. Derzeit ist sie nur für Solaris verfügbar, aber eine Portierung auf andere Plattformen wie Windows ist laut Aussage des Project Leads Chris Hegarty nicht mehr viel Arbeit  (siehe /SCTPPRT/).
• SDP . Java 7 wird das Socket Direct Protocol  (SDP, siehe /SDP/)  unter Solaris und Linux unterstützen.  Für den Java Programmierer gibt es kein neues API.  SDP kann vielmehr über die bisherigen Network-APIs wie Socket, ServerSocket, SocketChannel, ServerSocketChannel, AsynchronousSocketChannel und  Asynchronous ServerSocketChannel nach entsprechender Konfiguration des Systems (siehe /SDPCNF/) genutzt werden.
• TLS . Java 7 wird über bestehende APIs den Transport Layer Security (TLS) Standard in der neuen Version 1.2 unterstützen.
• IPv6 . Des Weiteren wird Java 7 die Nutzung des neuen mit Vista eingeführten, IPv6-fähigen Protokollstacks unter Windows unterstützen.  Auch dies wird über bestehende APIs verfügbar gemacht.

Project Jigsaw

Über die Modularisierung hat es heftige Diskussion  gegeben. Sun Microsystems hatte ursprünglich vor, im Rahmen von JSR 294 (Superpackages) und JSR 277 (Java Module System) ein Modulkonzept in Java einzuführen.  OSGi (Open Services Gateway initiative - JSR 291) enthält unter anderem auch ein Modulkonzept, dort "Bundle" statt "Module" genannt.  Lange und heftige Auseinandersetzung mit der OSGi Fraktion über Kompatibilität bzw. Inkompatibilität, Funktionsumfang, usw. haben am Ende dazu geführt, dass Sun Microsystems die Aktivitäten für JSR 294 und 277 Ende 2008 vorerst eingestellt hat.

Stattdessen wurde die Entwicklung eines einfachen Modulkonzepts gestartet, mit dessen Hilfe der JDK selbst modularisiert werden kann.  Wenn JDK-Benutzer dieses Modulkonzepts hilfreich finden, können sie es für ihre eigene Software gerne nutzen.  Dieses Konzept bzw. seine Implementierung ist "Project Jigsaw" und wird mit Java 8 freigegeben.

Type Annotations

Map<@NonNull String, @NonEmpty List<@Readonly Document>> files;
@NonNull Object @Nullable [] array;

Das Ziel dieser Spracherweiterung ist es, die Annotationen ganz generell als Typ-Qualifikatoren verwenden zu können.  Mit Hilfe der Annotationen kann in Java 8 das Typsystem der Sprache Java erweitert werden – ohne die Sprache ändern zu müssen - indem man Typen mit Hilfe von Annotationen näher beschreiben kann.  Diese Änderung der Java-Syntax wurde im JSR 308 (siehe /ANNOT/) beschrieben, der zwar bislang nicht formal verabschiedet wurde, aber in Java 8 implementiert werden soll.

Wozu braucht man das?  Ohne Werkzeuge, die diese neuen Möglichkeiten nutzen, machen die Typ-Annotationen keinen Sinn.  Deshalb werden begleitend zu den beschriebenen Sprachänderungen statische Analysewerkzeuge entwickelt, die anhand bestimmter Annotationen Fehler im Source Code aufzuspüren (siehe ebenfalls /ANNOT/).  Ein Beispiel für solche Annotationen sind @NonNull und @Nullable .   Die betreffenden Werkzeuge sollen verhindern, dass einer @NonNull -Variablen (die nicht null werden darf) der Wert null zugewiesen wird oder dass eine @Nullable -Variable (die den Wert null haben könnte) ohne Prüfung auf != null dereferenziert wird.  Diese Werkzeuge werden aber nicht Bestandteil von Java 8 sein, sondern Add-Ons, die man zusätzlich herunterladen und verwenden kann.

Project Lambda

Um die Syntax zu vereinfachen, soll es Lambda-Ausdrücke geben.  Anstelle von

new Thread(new Runnable { public void run() { System.out.println (“Hello World!”); } }).start();

new Thread( #{ System.out.println (“Hello World!”) ).start();

Das Sprachmittel der Lambdas ist in den Jahren 2006 bis 2008 sehr heftig diskutiert worden und es gab gleich drei konkurrierende Vorschläge dafür (siehe /CLDE/), damals noch unter der Bezeichnung "Closures".  Wegen des kontroversen Ansatzes der verschiedenen Vorschläge stagnierte das Thema für mehr als ein Jahr und es sah zunächst so aus, als wären Lambdas/Closures für Java gar kein Thema mehr.  Im November 2009 wurde die Idee wieder aufgegriffen  und in Java 8 sollen Lambdas dann verfügbar sein (siehe /BGOEL/).

Lambda-Ausdrücke werden u.a. für die ParallelArrays gebraucht, die ebenfalls mit Java 8 freigegeben werden sollen.  Die ParallelArrays sind ein Framework, dem man nur noch sagen muss, welche Funktionalität auf jedes einzelne Array-Element angewandt werden soll und der dann für die parallele Ausführung sorgt.  Die Lambdas würden die Benutzung der ParallelArrays drastisch vereinfachen, denn den syntaktischen Überbau für die Beschreibung der Funktionalität in Form von Interfaces und implementierenden Klassen könnte man mit Lambdas komplett eliminieren.
 

Zusammenfassung und Ausblick

Literaturverweise

Die gesamte Serie über Java 7:

If you are interested to hear more about this and related topics you might want to check out the following seminar:

Seminar   Effective Java - Advanced Java Programming Idioms  4 day seminar ( open enrollment and on-site)