"Auf Java-Entwickler kommt eine neue Syntax zu"

Claudia Fröhling

Wohin entwickelt sich die Java-Plattform? Welche Änderungen stehen mit den nächsten Releases an? Welche Herausforderungen werden konkret durch die Multicore-Prozessorarchitekturen der Chiphersteller gestellt? Welches Wissen über die technischen Interna und Optimierungsmöglichkeiten der JVM bringen meine Java-Projekte weiter? Antworten auf diese Fragen gibt es auf dem Java Core Day der JAX im Mai in Mainz. Wir haben vorab mit der Moderatorin des Tages, Angelika Langer gesprochen.

JAXenter: Der Java Core Day auf der JAX wird sich rund um das Thema Java-Plattform und neue Java-Versionen drehen. Was sind Ihrer Meinung nach die größten Herausforderungen für Java 7?

Angelika Langer: Die größte Herausforderung ist sicher, Java 7 endlich auf die Beine zu stellen.

Schon im Januar 2008 habe ich zusammen mit Klaus Kreft auf einer Konferenz in München über neue Feature in Java 7 referiert, in der Erwartung, dass Java 7 ein Jahr später verfügbar sein würde. Welch eine gigantische Fehleinschätzung! Seitdem ist viel Zeit vergangen, in der der Community Process praktisch am Boden gelegen hat. Außer Streit ist nicht viel passiert. Zwar haben wir jetzt einen Open JDK 7, der ohne Spezifikation einfach per Implementierung Fakten schafft. Dieses Vorgehen stößt aber bei vielen Benutzern in der Java Community auf Skepsis und entsprechend wird der Open JDK 7 eher selten verwendet.

Erfreulich ist, dass Oracle jetzt augenscheinlich in die Gänge kommt und den JDK 7 weitertreibt, auch den Community Process wieder beleben will und somit die Hoffnung besteht, dass wir in absehbarer Zeit einen Release 7 von Java SE sehen werden.

JAXenter: Auf der Devoxx 2009 wurde bekannt gegeben, dass Closures doch in Java 7 dabei sein werden. Dadurch hat sich nicht nur das Veröffentlichungsdatum von Java 7 verändert. Was bedeuten Closures konkret für Java-Entwickler?

Angelika Langer: Nun ja, ob die Verschiebung des Release-Zeitpunkts von Java 7 nun wirklich durch Closures verursacht ist, will ich mal dahin gestellt sein lassen. Wir wissen alle, dass auch gerne mal der nächstbeste plausible Grund hergenommen wird, um eine Verschiebung zu begründen, die ohnehin erforderlich gewesen wäre. Aber darüber möchte ich gar nicht spekulieren.

Die Wiederbelebung der Closure-Debatte (in Form von Project Lambda, wie es jetzt heißt) wird von Sun/Oracle damit begründet, dass der Fork-Join-Framework ohne Closures bzw. Lambda-Expressions sehr umständlich zu benutzen sei. Das ist sicher richtig, aber Fork-Join ist ein spezielles Concurrency-Feature, dass nur von einer Minderheit der Java-Programmierer benutzt werden wird. Deshalb ein neues Sprachmittel hinzufügen zu wollen erscheint wenig überzeugend.

Und prompt gibt es wieder Kontroversen und Meinungsverschiedenheiten. Alex Buckley von Oracle hat eine Spezifikation vorgelegt und Neil Gafter („Mr. Javac“, heute bei Microsoft) hat sofort zwei (!) überlappende Vorschläge verfasst. Neil würde Closures bzw. Lambdas so anlegen, dass sie auch User-defined Control Structures unterstützen. Alex Buckley hingegen hat so eine Art „Closures light“ vorgelegt, also eine einfachere Variante, die dann auch wirklich nur das Benutzen von Fork-Join erleichtert. Das ist jetzt sehr verkürzt dargestellt, aber darauf läuft es im Wesentlichen hinaus.

Neil Gafter kenne ihn schon von der C++-Standardisierung in den 90iger Jahren her und ich hätte ihn gerne im Core Java Track gehabt, aber es hat leider nicht geklappt. Ich weiss, dass Neil dank seiner langjährigen Erfahrung als Sprachdesigner und Compilerbauer sehr gut einschätzen kann, ob ein Sprachmittel funktioniert und wie es sich auf die Sprache insgesamt auswirkt. Zu einer bestehenden Sprache neue Sprachmittel hinzuzufügen ist trickreicher, als es sich die meisten Leute vorstellen.

Die größten Überraschungen entstehen immer dort, wo alte auf neue Sprachmittel treffen und in Kombination gelegentlich zu höchst subtilen Problemen führen. Das heißt, man muss ein solches Proposal gut durchdenken.

Im Augenblick scheinen mir die Anstrengungen zur Spezifikation von Closures bzw. Lambdas ein wenig kopflos. Es fehlt jemand bei Oracle, der die Kompetenz und Autorität hat, gut durchdachte Entscheidungen in der Sache zu fällen.

Ich denke, die Closures bzw. Lambdas werden kommen. Wie sie genau aussehen werden, bleibt abzuwarten. In jedem Falle kommt auf die Java-Entwickler neue Syntax zu, die es zu lernen gilt. Außerdem werden Closures bzw. Lambdas Elemente der funktionalen Programmierung in Java hineinbringen und damit wird verbunden sein, dass Java-Programmierer sich mit den Paradigmen der funktionalen Programmierung auseinander setzen müssen, soweit sie es nicht ohnehin schon getan haben.

Werden die Closures bzw. Lambdas so kompiziert und undurchsichtig sein wie die Generics? Ich denke nicht, aber einen gewissen Lernaufwand wird es schon erfordern. Aber was wäre die Alternative zu Lambdas in Java? Dass wir alle Scala lernen, um Fork-Join zu benutzen? Da wird es dann wohl doch einfacher sein, sich mit den Closures und Lambdas in Java anzufreunden.

JAXenter: Die Java-Plattform wurde ursprünglich für nur eine Programmiersprache gebaut: Java. Nun tummeln sich immer mehr Sprachen auf der Java VM und wollen es den Entwicklern einfacher machen. Welche Auswirkungen hat die neue Sprachvielfalt auf die Java-Plattform „unter der Motorhaube“? Werden dadurch die Dinge komplizierter oder bleibt alles beim Alten?

Angelika Langer: Eigentlich finde ich es sehr naheliegend, dass sich auf einer Architektur mit einer Zwischensprache und einer virtuellen Maschine eine Vielfalt von Sprachen entwickelt. Die .NET-Plattform war von vornherein als Multi-Language-Plattform angelegt; Java hat sich dazu entwickelt.

Für Java-Programmierer ändert sich dadurch nichts. Zwar ist mit invokedynamic nach vielen Jahren jetzt erstmals eine neue Byte-Code-Instruction hinzugekommen, aber die meisten Java-Programmierer werden damit überhaupt nichts zu tun haben, weil der Java-Compiler diese Instruction gar nicht generiert.

Was sich für Java-Entwickler vielleicht ändert, ist u.U. ein steigender Druck, Entwicklungen mit einem Mix von Programmiersprachen zu machen. Wenn spezielle Sprachen für die Lösung spezieller Probleme auf der Java VM zur Verfügung stehen, dann liegt es nahe, dass man sie einsetzt. Das kann man als Vor- oder Nachteil betrachten. Hybride Projekte, in denen eine Vielzahl von Sprachen im Einsatz sind, haben gelegentlich auch ihre Probleme damit.

JAXenter: Sie hosten den Java Core Day auf der JAX. Was können Teilnehmer von diesem Special Day erwarten und was sind Ihre persönlichen Highlights?

Angelika Langer: Ich habe versucht, ein bisschen was von dem zu zeigen, was sich am Kern der Sprache und der SE-Plattform in der letzten Zeit geändert hat. Dabei ging es mir in erster Linie darum, die Dinge vorzustellen, die auch tatsächlich zur Verfügung stehen und in der Praxis eingesetzt werden können. Wackelkandidaten wie Closures/Lambdas, Date/Time, und andere Neuheiten habe ich erst einmal zurückgestellt.

Dalibor Topic wird uns einen Einblick in den aktuellen Stand der Dinge bzgl. JDK 7 geben. Der Rest des Tages wird sich verschiedenen Neuerungen aus JDK 6 und 7 widmen:

  • Endlich haben wir ein vernünftiges API für Zugriffe aufs Dateisystem; das hat schon lange im JDK gefehlt. Ralph Meier wird das API vorstellen und auch auf Erweiterungen des NIO Packages eingehen.
  • Sun hat unter dem Namen „Project Jigsaw“ ein Modularisierungskonzept für den JDK entwickelt, das man auch für eigene Projekte verwenden kann. Es ist Sun’s Reaktion auf den Streit um OSGi einerseits und Superpackages (JSR 294) bzw. Modules (JSR 277) andererseits. Dalibor Topic wird uns erklären, worum es geht.
  • Viel Aufwand ist in den letzten JDK-Releases in die Garbage Collectoren der JVM gesteckt worden. Ich werde versuchen eine Orientierungshilfe für die Vielzahl der Optionen zu geben, die mittlerweile für die GC zur Verfügung stehen.
  • Klaus Kreft wird anschließend die Konzepte des neuen „Garbage First“ Collectors (kurz: G1) erläutern, mit dem alles viel einfacher werden soll. G1 ist in Java 7 als der Default-Garbage-Collector vorgesehen und wird dann alle Benutzer des Sun/Oracle-JDK betreffen.

Natürlich ist es nur eine Auswahl der Dinge, die in JDK 6 und 7 neu hinzugekommen sind. Beispielsweise sind die Annotations for Defect Prevention (JSR 305 und 308), der Fork-Join-Framework und einiges mehr unter den Tisch gefallen.

Persönliche Highlights gibt es für mich eigentlich nicht. Jigsaw und G1 sind spannende Themen, aber eigentlich leben wir ja an sich in spannenden Zeiten, was den Fortgang von Java angeht. Wann wird Java 7 wirklich kommen und was wird es dann tatsächlich enthalten? Und wie wird der angekündigte Merger der JRockit mit der HotSpot JVM aussehen? Da bin ich einfach neugierig.

Angelika Langer arbeitet als Trainer und Consultant mit eigenem Schulungsprogramm im Bereich der Software-Entwicklung mit C++ und Java. Sie ist Sprecher auf zahlreichen Konferenzen, darunter JavaOne, OOPLSA, JAX, und viele andere. Zusammen mit Klaus Kreft ist sie Autor zahlreicher Veröffentlichungen, darunter die Kolumne „Effective Java“ im JavaSpektrum sowie das online „Java Generics FAQ“. Weitere Informationen unter http://www.AngelikaLanger.com.

Geschrieben von
Claudia Fröhling
Kommentare

Schreibe einen Kommentar

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