Suche

Java 7: The Big Update

Internationalisierung

Mit Java 7 wird eine Reihe von Modernisierungen im Bereich der Internationalisierung berücksichtigt.

  • Unicode 6.0: Java-Programme verwenden den Unicode-Zeichensatz und jeder JDK unterstützt die jeweils aktuelle Version des Unicode-Standards – von Version 1.1.5 im JDK 1.0 bis zu Version 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 Unicode 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-österreichische 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, 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-Klassen zu unterschiedlichen Zwecken verwendet: einerseits für die Formatierung von kulturabhängigen Zahlen, Datums-, Zeit- und Währungsangaben und ähnlichem, andererseits für die sprachabhängige Darstellung und Verarbeitungen von Texten, die Anzeige von Benutzeroberflächen und ähnlichem. 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

Mit „NIO.2“ werden Ergänzungen zum Package java.nio bezeichnet. Die „alte“ I/O im Package java.io gibt es schon, seit es Java gibt, von kleineren Ergänzungen und Korrekturen einmal abgesehen. Mit Java 1.4 ist neue d. h. zusätzliche I/O-Funktionalität hinzugekommen. Dieser Funktionsumfang wurde NIO („new I/O“) genannt und befindet sich in dem Package java.nio. Mit Java 7 kommt nun weitere zusätzliche Funktionalität dazu, die im Java Specification Request [4] beschrieben ist:

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 Kommunikationsprotokoll, das im TCP/IP-Stack parallel zu TCP und UDP steht [5]. 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 [6].
  • SDP: Java 7 wird das Socket Direct Protocol (SDP, [7]) 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 [8] 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 Protokoll-Stacks unter Windows unterstützen. Auch dies wird über bestehende APIs verfügbar gemacht.
Project Jigsaw

Bei „Project Jigsaw“ geht es um ein Modulkonzept für Java. Ein bekanntes Defizit von Java ist, dass es keine Module kennt. Man kann heutzutage zwar eine Menge von zusammenhängenden Klassen und Ressourcen z. B. in einer jar-Datei zusammenfassen und hat damit so etwas wie ein Modul, aber es gibt keine Möglichkeit zu beschreiben, was ein Modul anderen Modulen zur Verfügung stellt, was es seinerseits wieder braucht und in welchen Versionen. Das Problem taucht beispielsweise auf, wenn man Software verwendet, die wiederum Software, z. B. „Apache Commons“, verwendet. Wenn nun die verwendete Software unterschiedliche Versionen von Apache Commons braucht, kann man die Commons-Bibliothek nur einmal einbinden. In welcher Version soll man das tun? Da nimmt man üblicherweise die jüngste und hofft, dass sie abwärts-kompatibel ist. Wirklich befriedigend ist diese Situation nicht. Was man braucht, ist zumindest eine klare Beschreibung von Export-, Import- und Versionsbeziehungen. Das ist eines der Probleme, die ein Modulkonzept lösen soll.

Über die Modularisierung hat es heftige Diskussionen gegeben. Sun Microsystems hatte ursprünglich vor, im Rahmen des 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 Auseinandersetzungen 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 Modulkonzept 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.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.