Unser Experten-Check zu Java 10 – Teil 5

11 Expertenmeinungen zu Java 10: Das modulare Ökosystem und Erwartungen für Java 11

Gabriela Motroc
Jaxenter

Im Rückblick fällt es ja oft leichter, Dinge zu bewerten. Daher haben wir unsere Experten gefragt, was sie von der Modulasierung in Java 9 halten. Und natürlich wollten wir wissen, was die Erwartungen für Java 11 sind. Denn schon in weniger als einem halben Jahr erwartet uns die nächte Java-Version.

Im letzten Teil unserer Interviewserie haben wir unseren Experten noch einmal zwei Fragen gestellt. Wie auch im ersten, zweiten, dritten und vierten Teil schon. Dieses Mal ging es um eine Einschätzung der Modularisierung, die mit Java 9 eingeführt wurde, und um die Wünsche (die wird man ja wohl noch haben dürfen) für Java 11.

Was hältst du vom modularen Ökosystem? Hast du es ausprobiert?

Die Java-Experten

Donald Smith ist Senior Director des Produktmanagements bei Oracle.

Dr. Wayne Citrin ist CTO und Co-Founder von JNBridge, LLC.

Greg Luck ist CEO und CTO von Hazelcast.

Lukas Eder ist Gründer und Leiter der Forschung und Entwicklung bei der Data Geekery GmbH, dem Unternehmen hinter jOOQ und Java-Champion.

Marcus Biel ist Software-Handwerker, JCP-Mitglied und CleanCode-Prediger.

Markus Eisele ist Leiter der Developer Advocacy bei Lightbend und Java-Champion.

Nicolai Parlog ist Entwickler (vor allem Java), Blogger bei CodeFX, Autor, YouTuber und Trainer.

Richard Gall ist Communications Manager bei Packt.

Simon Ritter ist der Vize-CTO von Azul Systems.

Trisha Gee ist Developer Advocate bei JetBrains, ein Key-Member der Londoner Java Community und Java-Champion.

David Heffelfinger ist Java-Champion und Jakarta EE Consultant und Ausbilder.

Wayne Citrin: Ich bin vom modularen Ökosystem begeistert. Was mir besonders gut daran gefällt, ist der Punkt, dass es Entwicklern erlaubt, erste Erfahrungen zu sammeln und den Prozess ihrem eigenen Tempo anzupassen. Ich selbst habe schon etwas damit rumgespielt und mir gefällt es sehr gut. Dennoch ist die Modularisierung unserer aktuellen Code-Basis für unsere Produkte nicht unsere Top-Priorität.

Simon Ritter: Ich halte das modulare Ökosystem für eine feine Angelegenheit. Java ist eine überzeugende Plattform mit einem sehr reichhaltigen Satz an Bibliotheken (es gibt über 4.500 Klassen in der JDK-8-Bibliothek). Das ist großartig, weil Entwickler nicht ihre eigene List-Schnittstelle oder Semaphore-Klasse schreiben müssen, sondern dass eine einzelne rt.jar-Datei das JDK monolithisch gemacht hat. Modularität bedeutet, dass wir jetzt Runtime Java Images erstellen können, die nur die Module enthalten, die für eine Anwendung oder einen Service benötigt werden. Das ist vor allem mit der zunehmenden Popularität von Microservices angemessen. Die Möglichkeit, eine Laufzeit zu erzeugen, die zusammen mit dem Service in einem Container verschifft wird, ist sehr effizient.

Richard Gall: Das modulare Ökosystem benötigt viel mehr Zeit, um flächendeckend genutzt zu werden. Es ist nur für große Projekte mit Hunderttausenden oder Millionen Zeilen Code geeignet, die von vielen Entwicklungsteams entwickelt wurden. Kleinere Projekte können auch so überleben und für die ist es eher ein Furunkel am… wo auch immer.

Trisha Gee: Ja, ich habe damit etwas herumexperimentiert, als ich meinen Code auf Java 9 migriert hatte. Allerdings habe ich nur wenige Module von anderen Leuten benutzt (außer den JDK-Modulen), da es zu wenige waren. Aber ich halte es für eine gute Idee, das Modulkonzept nativ in Java einzuführen. Die Zeit wird zeigen, wie das Ökosystem funktionieren wird.

Lukas Eder: Ich finde es im Hinblick auf die Zukunft des JDKs gut, dass es existiert. Mit Java 11 werden die Packages von Java EE (etwa JAXB) und CORBA endlich entfernt. CORBA wird wohl eher niemand vermissen und die meisten Nutzer können bei Bedarf die JAXB-Abhängigkeiten leicht hinzufügen. Dadurch wird das JDK schlanker, wovon alle etwas haben. Natürlich hätte man ein besseres Modulsystem bauen können, aber das wurde schon oft genug thematisiert, und mir persönlich ist es relativ egal.

Markus Eisele: Die Modularisierung ist nicht per se etwas Neues und es wurde bereits mehrfach festgestellt, dass sie in Java zu spät implementiert wurde, um wirklich effektiv zu sein. Entwickler können dieses Werkzeug auf verschiedene Arten einsetzen und ich habe den Eindruck, dass das Thema ein wenig intensiver besprochen wird in letzter Zeit. Das mag daran liegen, dass Entwickler mittlerweile tatsächlich anfangen, damit zu arbeiten. Mir hat zum Einstieg in die Modularisierungsthematik das Buch von Paul und Sanders „Java 9 Modularity – Patterns and Practices for Developing Maintainable Applications“ sehr geholfen.

Nicolai Parlog: Ich habe mit dem Modulsystem ein wenig herumgespielt, aber so wirklich genießen konnte bisher keiner die Vorteile des modularen Ökosystems, weil wir einfach noch nicht so weit sind. Es gibt schlicht nur sehr wenige Bibliotheken und Frameworks, die bereits modulare JARs liefern, was nachvollziehbar ist: Für Projekte birgt es wenig Vorteile, jedenfalls gilt das so lange, bis die Mindestanforderungen auf Java 9 angehoben wurde.

Trotzdem glaube ich fest daran, dass wir in wenigen Jahren definitiv mit einem modularen Ökosystem arbeiten werden. Das wird der größeren Java Community einiges über Modularität beibringen, genau wie Java 8 uns sehr viel über die funktionale Programmierung beibrachte.

Marcus Biel: Für mich persönlich ist der Einsatz von Java-Modulen ein guter Weg, um endlich eine wirklich saubere, modulare Architektur zu erhalten. Derzeit bereite ich einen Vortrag zu genau diesem Thema vor. Vor Java 9 war es ein Problem, dass man Architekturschichten zwar als theoretische Grenze definieren, sie aber nicht auch technisch durchsetzen konnte. Dadurch entwickelte sich eine monolithische Architektur schnell zu einem „Big Ball of Mud“.

In diesem Zusammenhang hatten Microservices natürlich einen großen Vorteil. Dadurch, dass sie in unterschiedlichen Umgebungen laufen, haben Sie sehr starke und klar definierte Grenzen. Das Java-Modulsystem bringt Entwicklern nun aber die Möglichkeit, starke und klare Grenzen zu haben, ohne auf die Einfachheit einer monolithischen Architektur verzichten zu müssen.

Greg Luck: Wir haben bereits ein modulares Ökosystem, das gut funktioniert. Es heißt Maven. Was mit der Java-Modularität gemacht wird, ähnelt OSGi, dem Modulsystem von IBM. Alle Modularitätssysteme zielen darauf ab, Komplexität zu überwinden und eine einfachere parallele und maßstabsgerechte Entwicklung zu ermöglichen. Was eine gute Sache ist. Alle versuchen, die Software-Prinzipien von Single Responsibility und Encapsulation durchzusetzen. Ebenfalls gute Dinge.

OSGi und die Java-Modularität sind Systeme zur Durchsetzung der Kompilierungszeit- und Laufzeitmodularität. Maven ist ein Baukastensystem von Abhängigkeiten. Ich dachte immer, dass die praktischen Probleme bei der Verwendung von OSGi die Vorteile überwiegen, sehe aber die gleichen Probleme bei der Modularität von Java. Hazelcast IMDG ist von einem Monolithen zu einem modularen System übergegangen, indem es sich in mehr als 35 Maven-Module aufgeteilt hat. Hazelcast Jet war immer als modulares System mit derzeit ca. 10 Modulen geplant. Wir haben 99% der Vorteile der Modularität mit abhängigkeitsbasierter Modularität.

David Heffelfinger: Ehrlich gesagt hatte ich bislang kaum Gelegenheit, Module zu verwenden, da ein Großteil meiner Arbeit noch in Java 8 liegt. Aber ich bin begeistert von den Möglichkeiten, die das Modulsystem bietet. Zum Beispiel haben wir traditionell Java-EE-Applikationsserver, die mehrere Implementierungen der verschiedenen Java-EE-Spezifikationen bündeln. Mit dem Modulsystem wäre es möglich, anstatt einen Applikationsserver herunterzuladen, einfach verschiedene Implementierungen der Java-EE-Spezifikation einzubinden und einen eigenen Applikationsserver mit unseren bevorzugten Implementierungen zu erstellen. Es würde auch ermöglichen, nur die Java-EE-APIs einzubinden, die tatsächlich in unseren Anwendungen benötigt werden. Auf der JavaOne-Konferenz vor ein paar Jahren gab es einige Gespräche über diese Möglichkeit. Ich hoffe, Jakarta EE bewegt sich in diese Richtung.

Was möchtest Du in Java 11 sehen?

Donald Smith: Ich bin begeistert, dass Java EE- und CORBA-Module entfernt wurden, sowie die Öffnung weiterer bisher geschlossener Oracle JDK Features wie Mission Control. Vor allem aber freue ich mich, dass die OpenJDK Builds von Oracle vollständig mit dem Oracle JDK austauschbar sind!

Wayne Citrin: Das könnte jetzt sehr speziell sein und nicht für alle von Interesse, aber ich möchte dynamische Klassengenerierung (d.h. Klassengenerierung zur Laufzeit) in Java implementiert sehen. In .NET gibt es ein sehr mächtiges Feature namens Reflection.Emit, das wir in unserer .NET-seitigen Programmierung verwenden. Es wäre schön, etwas ähnliches in Java zu haben. Im Moment verlassen wir uns auf eine Open-Source-Bibliothek namens BCEL, die zwar gut funktioniert, aber einfacher wäre es, wenn die dynamische Klassengenerierung in die Java-Plattform integriert wäre.

Simon Ritter: Da gibt es einige spannende Ideen für Änderungen an der Syntax von Java, die unter dem Projekt Amber zusammengefasst sind. Hoffentlich werden einige von ihnen (wie das Pattern Matching) es ins JDK 11 schaffen. Ich denke, dass diese nützlich wären.

Richard Gall: Value Types auf der JVM und Fibers, um mit Golang zu konkurrieren und die Möglichkeit zu haben, Swift und Golang effektiv für die JVM zu kompilieren. Bei beiden handelt es sich um großartige Sprachen.

Trisha Gee: Ich hoffe, dass wir Lambda Leftovers (JEP 302) bekommen. Ich bin sehr daran interessiert, es in meinem Code entsprechend ausdrücken zu können, wenn ein Lambda-Parameter absichtlich unbenutzt ist.

Lukas Eder: Bislang sieht das Release eher nicht so spannend aus (JDK 11) und ich hoffe, dass JEP 326 (Raw String Literals) mit Java 11 kommen werden. Wirklich jeder, der mit embedded SQL, XML, JSON, Regulären Ausdrücken, XSLT, CSV usw. arbeitet, wird Vorteile durch dieses JEP haben. Verglichen mit den Features aus Amber und Valhalla ist es ein absolut langweiliges Feature, das ist klar. Aber ich finde, dass es trotzdem ein sehr wertvolles Addendum zur Sprache wäre, ohne zu sehr in diese einzugreifen. Das JEP sieht jedenfalls sehr vielversprechend aus und ich hoffe wirklich, dass es Teil von Java 11 sein wird.

Auch das JEP 325 (Switch Expressions) sieht sehr cool aus. Die Entwickler anderer Sprachen haben bereits vor langer Zeit verstanden, dass es Vorteile hat, alles zu einer Expression zu machen. Statements sind sehr langweilige, prozedurale Konstrukte; Expressions sind bei der Implementierung eines funktional angehauchten Programmierstils sehr viel mächtiger. Aus Sicht eines SQL-Entwicklers ist das eine gute Sache. JEP 325 hat als sogenannter „Syntax Sugar“ gute Chancen, in Java 11 aufgenommen zu werden.

Natürlich gibt es noch eine ganze Menge mehr, auf das ich hoffe, aber die oben genannten Beispiele sind definitiv realistisch.

Markus Eisele: Ich habe für Java 11 derzeit keine spezifischen Wünsche. Ich glaube aber, dass es weitere Möglichkeiten gibt, Container-Umgebungen noch besser zu unterstützen. Aus Perspektive eines Entwicklers würde ich mich vermutlich sehr über Datenklassen (Data Classes) im JDK freuen.

Nicolai Parlog: Siehe meine obige Antwort. Ich vertraue dem Java-Team von Oracle, dass es die Sprache mit einer vernünftigen Geschwindigkeit vorantreibt und ich bin glücklich mit allem, was es schließlich in Java 11 schaffen wird.

Marcus Biel: Neben dem bereits erwähnten Pattern Matching warte ich darauf, dass Value Types in Java endlich Einzug halten.

Greg Luck: Typinferenz lokaler Variablen für Lambda-Methodenparameter und Werttypen.

David Heffelfinger: Im Laufe der Jahre wurden Funktionen, die früher populär waren, zu Java hinzugefügt. Einige dieser Funktionen sind nicht mehr so populär, aber aufgrund von Rückwärtskompatibilitätsproblemen können sie nicht wirklich entfernt werden. Das klassische Beispiel hierfür ist die CORBA-Unterstützung. CORBA war in den 1990er Jahren sehr beliebt, wird aber heute nur noch selten verwendet. Jetzt, da das JDK modular aufgebaut ist, können diese Legacy-Features aus Java entfernt werden, können aber als Module eingebunden werden, wenn jemand sie benötigt. Einige dieser Legacy-Features sollen in Java 11 entfernt werden, was zu einer schlankeren Java-Laufzeit führt.

Geschrieben von
Gabriela Motroc
Gabriela Motroc
Gabriela Motroc ist Online-Redakteurin für JAXenter.com. Vor S&S Media studierte Sie International Communication Management an der The Hague University of Applied Sciences.
Kommentare

Schreibe einen Kommentar

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