wake-up-neo.com

Wie kann man die Abhängigkeit von Java ee für den Übergang zu Java 9 ausdrücken?

Wir verwenden maven und haben Artefakte, die wiederum von anderen internen Artefakten abhängen. Ich bin gerade dabei, nach Java-9 zu migrieren, und beabsichtige, zunächst alles nach Java 9 zu migrieren, ohne den Code zu modifizieren (d. H. Im unbenannten Modul). 

Mein Problem ist, dass wir auf Java.xml.bind angewiesen sind, das jetzt nicht in den Standardmodulen enthalten ist. Gibt es eine "richtige" Möglichkeit, diese Abhängigkeit von Java.xml.bind mit Maven auszudrücken?

19
Kevin Peterson

Das Module System spricht davon, wie unbenannte Module beim Laden der Anwendung aus classpath den Modulgraphen erstellen. Weiter aus der Dokumentation selbst: -

Wenn der Compiler Code im unbenannten Modul oder in Java kompiliert Launcher wird aufgerufen und die Hauptklasse der Anwendung wird geladen vom Klassenpfad in das unbenannte Modul der Anwendungsklasse Loader, dann ist der Standardsatz von Root-Modulen für das unbenannte Modul wie folgt berechnet:

  • Das Java.se-Modul ist ein Stamm, falls vorhanden. Wenn es nicht existiert, dann jedes Java.*-Modul im Pfad des Upgrade-Moduls oder im System Module, bei denen exports mindestens ein Paket ohne Qualifikation ein .__ ist. Wurzel.

  • Jedes non-Java.*-Modul im Pfad des Upgrade-Moduls oder im System Module, bei denen exports mindestens ein Paket ohne Qualifikation .__ ist. auch eine wurzel.

Ansonsten hängt der Standardsatz von Root-Modulen von der Phase ab:

  • Zur Kompilierzeit ist dies normalerweise die Menge der zu kompilierenden Module (weiter unten.).

  • Zur Verbindungszeit ist es leer; und

  • Zur Laufzeit ist es das Hauptmodul der Anwendung, wie über die .__ angegeben. --module (oder kurz -m kurz) Launcher-Option.

Es ist gelegentlich erforderlich, dem Standardstammsatz in .__ Module hinzuzufügen. Um sicherzustellen, dass eine bestimmte Plattform, Bibliothek oder Diensteanbieter Module werden in der Modulgrafik vorhanden sein. In jeder Phase die Option

--add-modules <module>(,<module>)* Wobei <module> ein Modulname ist, fügt die benannten Module dem Standardsatz von Stammmodulen hinzu.

Ein ähnliches Problem wurde in jetty.project festgestellt, in dem ein thread aus der jdk-Mailingliste über dasselbe diskutierte und der Fix verwendet wurde:

--add-modules Java.se.ee

die ihnen Zugriff auf alle Java SE-Module gewährt haben und in Ihrem Fall einfach:

--add-modules Java.xml.bind

Um dies in maven zu verwenden, können Sie dasselbe mit maven-compiler-plugin.__ 

<compilerArgs>
    <arg>--add-modules</arg>
    <arg>Java.xml.bind</arg>
</compilerArgs>

wie von ZhekaKozlov vorgeschlagen hier .


Ein wichtiger Punkt zu beachten ist, dass das Markieren des Verfalls einer API auch bedeutet, dass Sie möglicherweise nicht mehr verwendet werden sollen. Um sich auf diese Weise anzupassen, können Sie wahrscheinlich die Abhängigkeit von jaxb-api:2.3.0 verbrauchen, die nun als Modul geladen werden kann und auch vom Klassenpfad aus ausgeführt werden kann. Die Änderung, die Sie vornehmen müssen, besteht darin, der Liste der Abhängigkeiten Folgendes hinzuzufügen:

<dependency>
    <groupId>javax.xml.bind</groupId>
    <artifactId>jaxb-api</artifactId>
    <version>2.3.0</version>
</dependency>

Update: - Eventuell mit Java-10 out und JDK/11 als nächstes sollte der Link zu JEP 320 folgen: Entfernen Sie die Java EE- und CORBA-Module und Ersetzen Sie solche Abhängigkeiten stattdessen durch ihre eigenständigen Bibliotheken.

20
nullpointer

Ja, Sie müssen --add-modules an den Java-Compiler übergeben:

<plugin>
    <groupId>org.Apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.7.0</version>
    <configuration>
        <release>9</release>
        <compilerArgs>
            <arg>--add-modules</arg>
            <arg>javax.xml.bind</arg>
        </compilerArgs>
    </configuration>
</plugin>

Dann sollte Ihr Projekt gut kompiliert werden.

11
ZhekaKozlov

JAXB sowie die anderen mit Java EE gemeinsam genutzten APIs (JAX-WS, JAF, JTA und die sogenannten "Common Annotations") werden in Java SE 9 nicht mehr unterstützt und sollen in einer zukünftigen Version von Java SE entfernt werden das JDK. Jede dieser APIs verfügt über eine eigenständige Version/Download. Jede API verfügt über eine eigene JSR, die diese auch verwaltet. Die Umstellung von den im JDK enthaltenen APIs auf die Standalone-Versionen wird natürlich etwas störend sein.

Ein erster Schritt zum Entfernen dieser APIs aus Java SE und dem JDK besteht darin, die Module, die diese APIs enthalten, standardmäßig nicht aufzulösen. Wenn Sie Code im Klassenpfad mit JDK 9 kompilieren oder ausführen, scheint die APIs anfangs nicht vorhanden zu sein. Wie in einer anderen Antwort beschrieben, ist eine schnelle Problemumgehung das Kompilieren oder Ausführen mit --add-modules Java.xml.bind. Diese CLI-Option fügt das Modul "Java.xml.bind" der Gruppe von Root-Modulen hinzu, die beim Start aufgelöst werden sollen. Es funktioniert mit JDK 9, da dieses Modul im JDK-Laufzeitabbild enthalten ist.

Neben der schnellen Problemumgehung müssen Anwendungen oder Bibliotheken, die JAXB verwenden, die Standalone-Version der API/Implementierung verwenden. JAXB 2.3.0 wird in Kürze bei Maven Central veröffentlicht und enthält die Änderungen für die Arbeit mit JDK 9 und darüber hinaus. Die Standalone-Version kann wie andere JAR-Dateien im Klassenpfad bereitgestellt werden. Es ist möglich, die Standalone-Version auf dem (Upgrade-) Modulpfad bereitzustellen und auch als Modul zu verwenden. Das JDK 9-Migrationshandbuch enthält weitere Informationen zu den Optionen für die Migration von Code, der JAXB oder die anderen mit Java EE gemeinsam genutzten APIs verwendet.

7
Alan Bateman

Okay, ich hoffe das hilft jemandem. Wenn Sie per Zufall Java 9 oder 10 installiert haben und feststellen, dass Sie diesen javax.xml.bind - Fehler nicht überwinden können, verwenden Sie möglicherweise Java 8 über jenv pro Ordner ( Es tut mir wirklich leid, so vage zu sein, aber das ist alles, wofür ich im Moment Zeit habe)? 

Durch das Hinzufügen einer korrekten Einstellung für Java_HOME wurde mein Problem behoben: export Java_HOME="$(/usr/libexec/Java_home -v 1.8)" unter MacOS.

0
Brett Tofel