Dies ist die Heimat der Java User Group Nürnberg.


Dienstag, 30. September 2008

Hex and the City: Java 7 Gerüchteküche

Hex and the City: Java 7 Gerüchteküche


Welche Neuerungen erwarten uns in Java 7?

Folgendes ist natürlich bloß als mögliche Neuerungen zu verstehen. Was tatsächlich in Java veröffentlicht wird (und wie es dann im Detail aussieht), werden wir wohl erst erfahren, wenn Java 7 erscheint1. Aber die folgenden Neuerungen sind im Gespräch.

Neuerungen allgemein
Während eine Applikation möglichst vollständig sein sollte, um dem Nutzer viele Featues zu bieten, sollte eine Sprache dagegen simpel aber ausreichend sein. Wir sollen kreativ mit der Sprache umgehen, aber nicht in ihr2. Und wir dürfen nicht vergessen, die Vergangenheit muss weiter leben3. Wir müssen also möglichst abwärtskompatibel bleiben. Jeder erinnert sich vielleicht, wie schlimm es war
enum als neues Schlüsselwort einzuführen - zumindest die, welche einst Variablen mit diesem Namen benutzt hatten. Daher wird mit der Weiterentwicklung und Auswahl neuer Features in der Sprache Java sehr vorsichtig umgegangen.

Superpackages
Diese neuen Module können "normale" Pakete und Klassen enthalten, und definieren, welche davon veröffentlicht werden (JSR 294). So kann ein Modul z.B. aus drei Paketen bestehen, die ihrerseits "public"-Klassen enthalten. Obwohl die Klassen durch eine "public"-Sichtbarkeit dann untereinander in den Paketen sichtbar sind, sind sie als Teil des Moduls vor der Öffentlichkeit versteckt, wenn das Modul selbst sie nicht zusätzlich als "public" definiert.

Ein Java Modul kann man dann als eine Art Jar (vielleicht ".JAM") mit erweiterten Metadaten, z.B. bessere Versionierung, verstehen (JSR 277). Die Versionierung schliesst zum Beispiel ein, dass man definiert, ein Modul A hängt von einem Modul B in der genauen Version 1.2.0 ab, während Modul B von Modul C in Version 2.0.3 oder höher abhängt. Durch die Module soll es dann auch möglich sein, eine Bibliothek in mehreren Versionen gleichzeitig in einem Prozeß zu haben, je nach Abhängigkeiten der Module. Ein Modulk welches wir benutzen könnte somit Log4J in einer alten Version nutzen, während unser eigener Code bereits die neues Version nutzt. Teilweise ist dies ja gerade dann wichtig, wenn Versionen nicht kompatibel sind. Mich erinnert das ganze sehr an die schöne Umsetzung der Assemblies in .NET, aber warum sollten Technologien auch nicht voneinander abgucken4.

Dank Module haben wir dann auch Laden on Demand und einen kleinen Memory Footprint. Die Java Laufzeit-Bibliotheken selbst werden dann vermutlich in Module getrennt, und bei Bedarf geladen. Auch Webstart-Anwendung können dann beschleunigt geladen werden, da wir besser regulieren können, was wirklich übertragen werden muss.

Ein Beispiel wie so ein Superpackages aussehen könnte:

src/com/foo/super-package.java:

superpackage com.foo {
member package com.foo.api,
com.foo.model, com.foo.util;
export com.foo.api; // public
}

Swing
Ein neues Swing-Applikations-Framework ist geplant, wie man es aus diversen anderen Rich-Client-Plattformen kennt (JSR 296). Dieser Container für Desktop-Anwendungen beinhaltet einen mächtigen ApplicationContext, der dann Tasks, Eventverarbeitung uvm. unterstützt. Da ich eher selten in der Client-Entwicklung tätig bin, werde ich dies nicht weiter ausführen5.

Annotationen
Die Annotationen aus Java 5 werden uns öfter begegnen. Demnächst sollen sie beinahe überall benutzt werden können, z.B. bei der Definition von Variablen in Methoden, mitten in Ausdrücken, bei Typ-Deklarationen... (JSR 308).


Auch wird Java um deutlich mehr Standard-Annotationen erweitert: @NonNull String, @Existing File, @UnmodifiableList, @NonEmpty Map (JSR 305). Diese sollen weit mehr Prüfungen durch den Compiler und automatisch zur Laufzeit ermöglichen. Demnächst sagen wir also nur noch


@NonNull String ichWerdeNieNull = "helloWorld"


und müssen uns über NullPointerExceptions nie wieder Gedanken machen6. Wir werden sehen, ob das holde Ziel wirklich erreicht wird. Ob die Annotationen den Code (gerade für "Nicht-Profis") besser lesbarer macht, stelle ich auch noch in Frage.

Generics
Das Problem, welches die Einführung von Generics in Java 5 und die gewünschte Abwärtskompabilität brachte, war das zur Laufzeit "ArrayList<String>" der gleiche Typ wie "ArrayList<Integer>" war. Per Reflection konnte man keinen Unterschied feststellen. Ebenso gab es bei generischen Konstruktoraufrufen oder erzeugen eines generischen Arrays Probleme. Dies soll mit einer besseren Laufzeitunterstützung von generischen Typen gelöst werden.

NIO2
Native IO 2 kommt (JSR 203) und bietet u.a. asynchrone APIs für den Zugriff auf Dateien und Sockets. Eine neue Filesystem API schenkt uns erweiterte Funktionalität im Bereich der Filesystem-spezifischen Daten (z.B. POSIX-Dateirechte). Desweiteren beinhaltet es Multicast-Unterstützung und Buffergrößen > int werden möglich sein.

JavaBeans
Innerhalb von JavaBeans gibt es einen neuen Bindungsmechanismus, der automatische Synchronisation zwischen JavaBeans-Properties ermöglicht. Die Bindungen sollen per Java-Code oder per JSP Expression Language definiert werden (JSR 295). Property-Typen die nicht direkt kompatibel sind, können dabei konvertiert werden. Zusätzlich wird ein Beans-Validierungs-Framework integriert, so dass Constraints auf Beans per Annotationen definiert werden können, wie man die bei Hibernate Validatoren kennt (JSR 303). Z.B. @Length(max=20) um festzulegen, dass ein Property maximal 20 Zeichen aufnehmen kann.


Properties
Um endlich von der Namenskonvention über get- und set-Methoden wegzukommen, mit der man Properties ja in Java momentan definiert7, sollen Properties in Java demnächst syntaktisch unterstützt werden. Dies wird letztlich wohl eine neue Schreibweise für solche Properties bedeuten, ermöglicht dann aber auch leichtere Analyse (z.B. für Designertools), was wirklich Properties sind, und leichte Kontrollierbarkeit, dass beim "get" auch wirklich nur gelesen wird.

Closures
Funktionen, die rumgereicht werden können. So könnte man Closures lapidar bezeichnen. Closures sind eine Art von Codeblöcke, die man ähnlich Funktionen definieren kann, und die man dann wie einen Parameter verwenden kann. Ein Closures besteht dabei aus einer Liste von möglichen formalen Parametern (oder keine, wenn keine benötigt werden) und eine Folge von Ausdrücken. Das ganze in geschweiften Klammern und getrennt durch "=>". Also sieht ein Closure folgendermaßen aus:

{ formale Parameter => Ausdrücke }

Ein Closure, welches einer Funktion ohne Parameter und "void" als Rückgabetyp entspricht, wäre:

{ => System.out.println("Hello World"); }

Soll das Closure einen String als Parameter bekommen, müssen wir es entsprechend anpassen:

{ String s => System.out.println(s); }

Jetzt können wir eine Variable definieren, der genau ein solches Closure zugewiesen werden kann:

{ String => void } print =
{ String s => System.out.println(s); };

Diese Variable können wir jetzt entsprechen an Methoden, etc. weiterreichen und letztlich die darin "gekapselte" Funktion aufrufen:

print.invoke("Hello World");

Die Schreibweise war an dieser Stelle beispielhaft. Wie das genau aussehen wird, falls Closures eingeführt werden, ist noch ungewiss, aber es gibt bereits dergleich gestalte Umsetzungen.

Zusatz zu den Closures: Nach einem Gespräch mit James Gosling (der "Vater" von Java) auf dem Herbstcampus, scheinen Closures wohl doch nicht in Java 7 zu erscheinen. Josh Bloch hat wohl sein Veto dagegen erhoben, nachdem er trotz anfänglicher Begeisterung Closures plötzlich nicht mehr mochte. Diese Erkenntnis hatte Bloch wohl bei einem Frühstück, bevor er auf einer Konferenz über Closures (positiv) reden wollte. Kurzerhand hat er seinen Vortrag dann umgeworfen und war gegen die Einführung von Closures in Java 78.

Skriptsprachen und Co.
Zusätzlich wird es vermutlich mehr Skriptsprachen geben, die auf der Java VM laufen sollen9. Um gerade die Sprachen ohne starke Typprüfung (also z.B. JavaScript, Ruby, Python) besser zu unterstützen, muss eine Möglichkeit geschaffen werden, das Ziel eines Methodenaufrufes dynamisch zu bestimmen. Dazu muss der Java-Bytecode um ein "invokedynamic" erweitert werden (JSR 292).

Uhrzeiten
Na endlich. Es soll Aufräumarbeiten bei Date/Time geben. Man kann es kaum glauben, das ist ja, als wenn der Osterhase um den Weihnachtsbaum tanzt. Endlich nicht mehr Monate von 0 – 11 trotz Tage von 1 - 31. Und nicht mehr tausende von deprecated-Methoden, die dennoch genutzt werden, weil es eigentlich nichts besseres gibt. Und dann nach dieser halbgare
Calendar, welch ein Graus. Jetzt besteht also Hoffnung für alle, die meine Meinung da teilen (JSR 310). Dazu vgl. man die JodaTime-Bibliothek.

Einheiten
Die Physiker unter uns werden sich freuen. Es gibt Chancen darauf, dass in die Libraries neue Pakete aufgenommen werden, die (physikalische) Einheiten und Quantitäten und das Umrechnen/Konvertieren dieser von Haus aus ermöglichen (JSR 275). Ich finde ja, dass ganze ist zu speziell um in Java direkt integriert zu werden, aber solange es Module gibt und die VM diese nur bei Bedarf nachlädt, kann ich damit leben. Das Ganze könnte dann wie folgt aussehen:

KILO(METER).getConverterTo(MILE).convert(10);

JMX 2.0
Die neue Version soll kommen. Und neue Annotation mit sich bringen, mit der man viel Schreibarbeit sparen kann (JSR 255). Desweiteren gibt es einen neuen Remote Connector, der die Anbindung als Webservices möglich macht (JSR 262).

BigDecimal
Endlich arithmetische Operatoren ("+", "-", ...) für BigDecimal-Typen. Juchuuu. Das brauchte die Welt ja schon lange.

String & Switch
String-Literale für Case kommen als Erweiterung der Syntax. Gar nicht mal so schlecht.

XML
Als besonderer "Freund" von XML10 (), musste ich Arg die Stirn runzeln, als ich von folgender Neuerung gehört habe. Allerdings bin ich auf der anderen Seite ein Liebhaber von allem, was wir uns der Compiler prüfen kann. XML soll syntaktisch in Java integriert werden können. Das sieht dann ungefähr wie folgt aus:

void addReviewer (XML feature,
String reviewer, Timestamp time) {
DataCoder dc = DataCoder.XSD;
feature.add(<reviewed>
<who>{ reviewer }</who>;
<when>{ dc.encode(time) }</when>;
</reviewed>);
}

Nachdem ich LINQ in C# liebe, gerade weil man keine Strings mehr schreibt, die einem zur Laufzeit irgendwann um die Ohren schlagen, sondern vom Compiler geprüft werden, kann ich den Ansatz hier irgendwie wohl nicht verteufeln. Allerdings ist LINQ eine Query Language, und das hier ist XML!!! Gebt uns lieber eine Query Language (quasi wie SQL nur nicht bloß auf Datenbanken beschränkt), die Syntaxgeprüft werden kann, statt XML. Aber das ist meine Meinung.

Enumerationen
Vergleichsoperatoren bei Enumerationen sollen nutzbar werden.


Insgesamt freuen wir alle uns bestimmt schon auf das neue (siebte) Spielzeug ;-)


Links:

http://tech.puredanger.com/java7

http://gafter.com/~neal/

http://de.wikipedia.org/wiki/LINQ


1Aber wie ja bekannt sein dürfte, was geschrieben steht ist wahr. Also definieren wir doch einfach einmal die Wahrheit.

2Wobei ich das selbst manchmal ja auch tue: Entschuldigung. Ich verweise da insbesondere auf die Kolumne Deutsch für Informatiker in der letzten Ausgabe von Norbert Petsch.

3Was man so unter leben versteht. Aber immerhin laufen auch noch Computerprogramme, die vor Jahrzehnten entwickelt wurden. Und die will niemand (naja, kaum jemand) umbauen, bloß weil eine neue Version der Sprache erscheint.

4Gerade wo momentan die verantwortlichen Personen ja auch so schön herum wandern, Neil Gafter geht ja jetzt auch zu Microsoft von Google und noch früher von Sun.

5Und davon abgesehen, wer will schon Swing-Applikationen bauen?^^

6Ähnlich wie jeder Java-Umsteiger aus der C++-Welt lernte: Du musst Dir um Pointer keine Gedanken machen. Und dann kam die erste NullPointerException.

7Was ich ziemlich grausig finde, aber die Gründe sprengen jetzt hier den Rahmen und meine Zeit^^

8Ich recherchiere noch, was er gefrühstückt hat.

9Wems Spaß macht ;-)

10Wo es Sinn macht, sehe ich es ja ein, leider wird es so oft ohne entsprechenden Sinn benutzt.

Keine Kommentare: