Suche
Unser Experten-Check zu Java 10 – Teil 3

11 Expertenmeinungen zu Java 10: Migration auf Java 10 und der Weg zu Java 9

Gabriela Motroc
Jaxenter

Kommt Java 10 überhaupt bei unseren Experten zum Einsatz? Und wie war die Umstellung auf Java 9? Lohnt es sich, jetzt alle sechs Monate so einen Prozess durchzuarbeiten? Wie schon im ersten und zweiten Teil unserer Interviewserie gehen auch hier die Meinungen wieder auseinander.

Nachdem wir im ersten Teil unserer Interviewserie nach Besonderheiten und persönlichen Highlights gefragt haben, sind wir im zweiten Teil Missverständnissen und austauschbaren Features auf der Spur gewesen. Dieses Mal geht es um die Migration von Java 9 und die Frage, ob diese vorherige Version überhaupt schon bei allen läuft.

Java 10 ist keine Version der Sprache mit Langzeitsupport, aber trotzdem sind die meisten unserer Experten neugierig. Persönliche Projekte und Demos sind da relativ einfach zu migrieren, aber bei größeren Projekten sieht es anders aus. Darum interessierte uns auch, ob viele überhaupt schon auf Java 9 umgestellt hatten und wie da der Prozess gelaufen ist. Es stellt sich heraus: Schon der Vorgänger von Java 10 wird noch lange nicht von allen unseren Experten genutzt.

Wirst du zeitnah auf Java 10 umstellen?

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: Unsere Produkte müssen auf allen Java-Versionen ab Java 5 lauffähig sein. Wir haben unsere Produkte an Java 10 getestet und es gibt keine bahnbrechende Veränderung. Trotzdem planen wir derzeit nicht, unsere Produkte für Java 10 neu einzustellen.

Simon Ritter: Ich werde es für den Demo-Code verwenden, den ich schreibe. Da ich keinen Code für die Produktion mehr schreibe, habe ich mehr Flexibilität bei der Verwendung des JDKs, und ich muss mich nicht so sehr um Updates kümmern.

Richard Gall: Nein, eher damit spielen. Immerhin ist Java 10 keine Version mit Langzeitsupport.

Trish Gee: Ich habe bereits einige Code-Beispiele in Java 10 geschrieben. Es ist möglich, dass ich einige meiner Demos auf die neue Sprachversion migrieren könnte, um zu sehen, ob es einen wesentlichen Einfluss auf die Lesbarkeit oder Leistung des Codes hat.

David Heffelfinger: Ich kann bei einigen meiner persönlichen Projekte migrieren. Ich arbeite als Berater und die meisten meiner Kunden sind große, konservative Organisationen, die sehr risikoscheu sind. Aus diesem Grund werden die meisten wahrscheinlich für einige Zeit nicht auf Java 10 migrieren.

Lukas Eder: jOOQ wird Java 10 auf jeden Fall unterstützen. Auch die Integrationstests von jOOQ werden möglicherweise auf Java 10 migriert, da diese ebenfalls von JEP 286 profitieren.

Markus Eisele: Ich nutze Java 10 bereits seit einiger Zeit. Teste früh und oft, so heißt es. Ich bin der Auffassung, dass jeder Betaversionen nutzen sollte, sobald sie verfügbar sind. Es ist die Aufgabe der Community, Schwierigkeiten und Bugs zu entdecken.

Nicolai Parlog: Ja. Das funktioniert relativ problemlos und es gibt keine öffentlichen Updates mehr für Java 9, also ist das unausweichlich.

Marcus Biel: Als Java Influencer habe ich natürlich bereits mit den Early-Access-Versionen von Java 10 experimentiert und werde so schnell es geht migrieren. Meine Kunden haben allerdings gerade erst auf Java 8 aktualisiert, es wird also leider noch etwas dauern, bis auch sie Java 10 nutzen werden.

Donald Smith: Ich habe Java 10 bereits zu meinem Basis-JDK für Demos und Präsentationen gemacht.

Greg Luck: Hazelcast hat zwei Open-Source-Projekte: Hazelcast In-Memory Data Grid, das bekannteste Projekt aus unserem Portfolio, und das neue Hazelcast Jet, eine Stream Processing Engine. Hazelcast IMDG ist auf Sprachniveau Java 6, während Jet auf Java-8-Sprachniveau ist.

Hazelcast IMDG hat 49 Millionen Call Homes im Monat – eine große Anzahl an Installationen. Stand Ende Februar 2018 verwendeten 95 Prozent der Hazelcast-IMDG-Anwender ab Version 3.6 als Sprachversion Java 8. Dies ist ein Anstieg von 77 Prozent, die im September 2016 gemessen wurden. Die Frage ist also nicht, wann wir auf Java 10 migrieren, sondern wann wir auf Java 8 für IMDG migrieren werden.

Für Jet haben wir erst im Februar 2017 die erste öffentliche Version herausgebracht. Wir werden auf eine neue Version von Java upgraden, wenn es genügend attraktive Features gibt, um dies zu rechtfertigen. Und das unterstreicht für mich ein ernsthaftes Problem mit der schnellen Veröffentlichung von Java-Versionen: Während es für Anwendungen einfach ist, auf das neueste JDK umzusteigen, ist das für Infrastrukturanbieter nicht so einfach, da sie an alle Nutzer denken müssen.

Hast du deine Projekte bereits auf Java 9 umgestellt? Wie war der Prozess?

Wayne Citrin: Wir bauen unseren Code aktuell auf Java 8, aber wir haben unsere kompilierten Produkte an Java 9 getestet und es funktioniert einwandfrei. Es gab eine wichtige Änderung am API für die Versionierung und dem Schema, aber das Problem war leicht zu beheben. Ich bin auf die Multi-Release JAR Files in Java 9 gespannt. Aber bisher waren wir noch nicht darauf angewiesen, die Vorteile der sprachspezifischen Features von Java 9 oder 10 zu nutzen. Ich bin mir sicher, dass sich das bald ändern wird.

Simon Ritter: Ich habe das JDK 9 für einige Demos verwendet. Im Großen und Ganzen fand ich die Umstellung ziemlich einfach. Ich denke, wenn man interne APIs (wie sun.misc.Unsafe) entweder direkt oder indirekt (über ein Framework oder eine Bibliothek von Drittanbietern) verwendet, würde das mehr Arbeit erfordern.

Richard Gall: Das kann ich nicht eindeutig beantworten. Es gibt Projekte, bei denen ich meine Finger im Spiel habe, die umgestellt wurden (hauptsächlich FOSS). Andere blieben bei Java 8 oder Java 6.

Trisha Gee: Ja, das habe ich gemacht. Und es war sehr schmerzhaft, da ich sehr früh umgeschaltet habe – ein Jahr vor dem eigentlichen Release. Das hatte zur Folge, dass viele meiner benutzten Libraries und Tools noch keinen richtigen Support für Java 9 anboten. Aber es lohnte sich trotzdem, da ich a) einen vorzeitigen Blick auf Java 9 bekam und sehen konnte, wie es sich anfühlt, damit zu arbeiten und wo möglicherweise Schwierigkeiten liegen könnten (natürlich auch, um Bugs und andere Probleme zu melden!) und b) dabei helfen konnte, nützliches Feedback für die Tools und Libraries zu geben, die nicht mit Java 9 zusammen funktionierten, damit diese zum offiziellen Start von Java 9 bereit sein konnten. Ich glaube, dass die Migration auf Java 9 mit der jetzt veröffentlichten Version sowie die Unterstützung der Tools und Bibliotheken, wie sie jetzt sind, relativ einfach wäre.

David Heffelfinger: Ich habe in einigen meiner Projekte auf Java 9 migriert. Allerdings arbeite ich in erster Linie mit Java EE und einige Java-EE-Applikationsserver laufen nicht richtig auf Java 9. Deshalb verwenden einige meiner Projekte immer noch Java 8.

Lukas Eder: Es war unvermeidbar, dass jOOQ Java 9 unterstützt (auch wenn es aktuell in Version 3.10 noch nicht modularisiert ist). Unsere anderen Bibliotheken (jOOλ, jOOR, jOOU, jOOX) sind bereits modularisiert und als Cross-Release-Artefakte veröffentlicht. Es war recht unkompliziert diese Bibliotheken zu modularisieren, das sieht bei jOOQ ein wenig anders aus, da es intern abhängig von JAXB ist. Es ist für Anbieter von Bibliotheken nicht gerade leicht, problemlos auf Java 9 zu upgraden, da haben es die Nutzer ein wenig leichter und es gibt tonnenweise gute Blogs, die die Probleme dokumentieren. Der von Nicolai Parlog, den ich kürzlich erst interviewt habe, gefällt mir dabei besonders gut.

Markus Eisele: Ich habe bei meinen Hobbyprojekten einige lokale Tests durchgeführt, aber nichts, was ernsthaft genug wäre, um es als „Prozess“ zu bezeichnen. Ich habe mich recht strikt an die offizielle Migrationsanleitung von Oracle gehalten und bin auf keinerlei Schwierigkeiten gestoßen.

Nicolai Parlog: Öhm, intensiv? 😊 Je größer die Codebasis, desto größer sind die Herausforderungen bei der Migration, denen man aller Voraussicht nach begegnen wird. Viele von ihnen fühlen sich zudem an wie absolut faszinierende Unfälle – davon hatte ich eine ganze Menge. Diese Probleme zu lösen bedeutete oftmals, einige Technische Schulden zu begleichen, weshalb ich den Aufwand nicht als Verschwendung ansehe.

Marcus Biel: Ich habe meine eigenen Projekte im letzten Jahr auf Java 9 migriert. Mit IntelliJ IDEA ist die Migration auf Java-9-Module wirklich ein Traum! Mit Eclipse Oxygen läuft das nicht ganz so gut, aber das wird sich hoffentlich mit der nächsten Version ändern.

Greg Luck: Sowohl für IMDG als auch für Jet haben wir überprüft, dass sie mit Java 9 gebaut und ausgeführt werden können.

Hazlecast IMDG 3.10 und Hazelcast Jet 0.6, die beide im April erscheinen, werden Java 9 unterstützen. Aber keins von beiden wird das Java-9-Sprachniveau verwenden.

Für Jet haben wir sorgfältig die Modularisierung von Java untersucht, um zu sehen, ob wir sie auf eine Art nd Weise hinzufügen könnten, dass sie von Java 9 erkannt wird, aber Java 8 nicht beeinträchtigen würde. Das funktioniert nicht. Man erhält den folgenden Compilerfehler, wenn man es versucht:

 
Error:(1, 1) java: modules are not supported in -source 1.8
(use -source 9 or higher to enable modules)

Also, kein module-info.java. Aber wenn jemand versucht, nicht-modularisierten Code aus Java 9 zu verwenden, indem er die Bibliothek dem Modulpfad hinzufügt, dann wird er verfügbar gemacht. Diese Module werden als Automatikmodule bezeichnet. Der Name des Automatikmoduls ist jedoch der Jar-Name. Eine gute Praxis, die wir unseren neuen Releases hinzugefügt haben, ist die Erstellung stabiler Namen für diese automatischen Module. Dies geschieht durch Hinzufügen eines Automatic-Module-Entry-Eintrags zu unseren Jar-Manifesten.

Unsere stabilen Namen sind:

Haselcast IMDG
Automatic-Module-Name: com.hazelcast.jet

Hazelcast Jet
Automatic-Module-Name: com.hazelcast

Ein weiteres Problem des Modulsystems in Java 9 ist, dass ein Paket vollständig in einem Modul enthalten sein muss. Klingt nach einer guten Idee, aber praktisch haben wir einen Code mit den gleichen Paketen in unseren Clients und auf unserer Serverseite. Das zerstört also das Modulsystem. Dies erfordert daher eine umfassende Refactoring-Maßnahme.

Wir haben auch andere Dinge wie den Management Center und unsere vielen Module. Management Center wird in der Version 3.10 auf Java 9 aktualisiert. Einzelne Module werden, getrieben von den jew. Communitys, die sie nutzen, auch ihre Sprachniveaus verbessern.

Im vierten Teil unserer fünfteiligen Interviewserie äußern sich unsere Experten zur neuen Release-Kadenz und geben Ratschläge, ob sich Legacy-Entwickler um Java 10 Gedanken machen sollten.

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
  1. TestP2018-04-09 12:59:24

    Übersetzungsfehler? Im Original heisst es:

    "Simon Ritter: I will certainly use it for demo code I write. Since I don’t write production code anymore, I have more flexibility on which JDK I can use, and I don’t need to be quite so concerned about updates."

    "Serieller Code" scheint nicht richtig zu sein.

    MfG

  2. Dominik Mohilo2018-04-09 14:15:50

    Hallo TestP,

    danke für den Hinweis :-)

    Liebe Grüße,
    Dominik Mohilo

Schreibe einen Kommentar

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