Eclipse ne peut pas trouver les classes liées à XML après avoir changé le chemin de génération vers JDK 10

Question

Je suis sur un projet Maven (direction générale de la plate-forme bom_brussels-sr7) dans Eclipse. Lorsque j'ai récemment essayé de commutation le Java Build Path du projet de JDK 10, Eclipse construire ne peut plus trouver des cours tels que l' javax.xml.xpath.XPath, org.w3c.dom.Documentou org.xml.sax.SAXException. Il semble XML classes associées sont touchés, surtout à partir de la dépendance Maven xml-apis-1.4.01.

Essayer un build Maven Eclipse fonctionne sans erreurs. Ctrl-LeftClick sur l'un des soi-disant classes manquantes trouve la classe et l'ouvre dans l'éditeur Eclipse. Il semble que l'Éclipse de construire est impacté.

J'ai essayé plusieurs choses, mais aucun ne l'a aidé. J'ai essayé:

• Projet Propre
• Différentes Versions d'Eclipse: de l'Oxygène et de Photons.
• Eclipse avec JDK JDK 8 et 10.
• Changer de Compilateur niveau de Conformité pour le projet. Il s'appuie sur la conformité de niveau 8 et 10 sous JDK 8 chemin de génération et d'échec pour les deux avec JDK 10 dans le build path.

Answer 1

Je suppose que le projet en cours de migration à partir de Java 1.8 n'a pas encore d' module-info.java. Cela implique que vous compilation d'un code dans le "sans nom de module".

Code dans le sans nom module "lit" tous les observables nommés ou anonymes modules, en particulier, il lit module "java.xml" à partir de la JRE System Library. Ce module exportations paquet comme java.xml.xpath.

En outre, vous avez xml-apis.java sur le chemin de la classe, ce qui contribue à une autre série de paquets de la même noms (java.xml.xpath et les amis). Ce sont dit d'être associé à sans nom de module, comme votre propre code.

Cette situation viole l' exigence de "une visibilité unique" tel que défini dans JLS §7.4.3 (dernier paragraphe). En particulier, tous les qualifiés du nom de type Q. Id (JSL §6.5.5.2) exige que son préfixe Q est un unique visible paquet (je suis ignorant le cas d'imbrication des types pour des raisons de simplicité). Ergo: le programme est illégale et doit être rejeté par les compilateurs.

Ce qui nous laisse avec une question et deux solutions:

(1) Question: Pourquoi est-javac accepter le programme?

(2) Solution: Si vous ajoutez module-info.java de votre projet, vous pouvez contrôler via nécessite le module de votre projet de lit, soit requires java.xml; ou requires xml.apis; (où "xml.api" est le module automatique nom de "xml-apis-1.4.01.jar).

(3) la Solution: Court de transformer votre projet en un module, vous pouvez encore éviter le conflit en excluant java.xml de l'ensemble des observables modules. Sur la ligne de commande ce qui serait fait à l'aide d' --limit-modules. L'équivalent dans Eclipse est la "Modularité Détails" de la boîte de dialogue, voir aussi le JDT 4.8 Nouveau et digne d'intérêt (voir le Contenu de l'onglet). Depuis java.xml est implicitement requise par beaucoup d'autres par défaut observables modules, il peut être une bonne idée de pousser tout, sauf pour java.base à partir de la droite ("Explicitement inclus les modules") à gauche ("modules") (et de manière sélective rajouter les modules besoins de votre projet).

PS: Eclipse ne propose pas encore un idéal de message d'erreur, au lieu de "ne peut pas être résolu", il devrait en fait dire: "Le package javax.xml.xpath est accessible à partir de plus d'un module: javax.xml, <sans nom>.

PPS: Aussi bizarre: comment se fait-que la modification de l'ordre entre les JRE et un jar dans le classpath (par exemple la commande n'est pas un concept soutenu par javac ni JEP 261) modifie le comportement du compilateur.

Modifications:

• Alex Buckley a confirmé que la situation est illégale, en dépit de ce que javac dit. Bug contre javac a été soulevée comme JDK-8215739. Ce bogue a été reconnue mois avant la sortie de Java 12. Comme de 2019-06 il a été décidé également de Java 13 expédier sans un correctif. De même pour Java 14.
• Eclipse message d'erreur a été améliorée de mentionner le réel problème.
• Dans Eclipse 2019-06 l'INTERFACE utilisateur utilisé pour la Solution (3) a été remanié. La mise à jour de la documentation peut être trouvée dans l' aide en ligne.

Answer 2

Cela semble avoir été signalé comme bogue Eclipse 536928 . Peut-être que si tout le monde allait voter là-dessus, cela les amènerait à augmenter la priorité.

Answer 3

Avoir vu quelque chose de très similaire sous Eclipse 4.8.0 et JDK 10. E. g.

import org.w3c.dom.Element;

a défaut de compiler dans Eclipse avec: The import org.w3c.dom.Element cannot be resolved

Même si, en appuyant sur F3 (Déclaration Ouverte) sur l'importation, l'Éclipse a été en mesure d'ouvrir la définition de l'interface - dans ce cas, en vertu de l' xml-apis-1.4.01.jar.

Pendant ce temps, construit à partir de Maven direct fonctionnent très bien.

Dans ce cas, la solution était de supprimer cette dépendance de l' pom.xml:

    <dependency>
        <groupId>xml-apis</groupId>
        <artifactId>xml-apis</artifactId>
        <version>1.4.01</version>
    </dependency>

Ensuite, les erreurs de compilation dans Eclipse fondu. Suivant F3 a de nouveau montré l' Element interface - maintenant, en vertu de l' java.xml module, en vertu de la JRE System Library dans le cadre du projet. Aussi le Maven build sont restés beaux.

Cela ressemble à un problème avec l'Éclipse de la résolution d'une classe qu'elle trouve à la fois un JDK module et dépendante .fichier jar.

Il est intéressant de noter, dans un environnement distinct, cette fois sous Eclipse 4.9.0 et JDK 11, tout est très bien, avec ou sans l' xml-apis:1.4.01 de dépendance.

Answer 4

Il s'agit plus d'une solution de contournement, mais d'après mon expérience, cela peut être résolu en allant dans le "Java Build Path", l'onglet "Order and Export" et en envoyant les "Maven Dependencies" en bas (c'est donc en dessous du "Bibliothèque système JRE").

Answer 5

jdk 9+ a apporté des changements liés au puzzle du projet. JDK a été décomposé en différents modules et certains modules, liés à javaee, jaxb et xml, ne sont plus chargés par défaut. Vous devez les ajouter directement à votre build maven, au lieu de vous attendre à ce qu'ils soient dans le chemin de classe jre. voir cette question SO