web-dev-qa-db-fra.com

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

Je développe sur un projet Maven (branche plate-forme-bom_brussels-sr7) sous Eclipse. Lorsque j'ai récemment essayé de basculer le chemin de génération Java du projet vers JDK 10, la génération Eclipse ne peut plus trouver de classes telles que javax.xml.xpath.XPath, org.w3c.dom.Document ou org.xml.sax.SAXException. Il semble que seules les classes liées à XML soient touchées, principalement par la dépendance Maven xml-apis-1.4.01.

Essayer une version Maven à partir d’Eclipse fonctionne sans erreur. Ctrl-LeftClick sur l'une des classes supposément manquantes trouve la classe et l'ouvre dans l'éditeur Eclipse. Il semble que seule la construction Eclipse soit impactée.

J'ai essayé plusieurs choses, mais aucune n'a aidé. J'ai essayé:

  • Projet Clean
  • Différentes versions d'Eclipse: Oxygen and Photon.
  • Lancer Eclipse lui-même avec JDK 8 et JDK 10.
  • Modification du niveau de conformité du compilateur pour le projet. Il génère avec les niveaux de conformité 8 et 10 sous le chemin de génération JDK 8 et échoue pour les deux avec le chemin de génération JDK 10 dans.
javaeclipsemavenjava-10
12
Carsten

Cela semble avoir été rapporté comme Eclipse Bug 536928 . Peut-être que si tout le monde allait voter, cela les inciterait à augmenter la priorité.

5
Garret Wilson

Je suppose que le projet en cours de migration de Java 1.8 n'a toujours pas de module-info.Java. Cela implique que vous compilez du code dans le "module non nommé".

Le code dans le module non nommé "lit" tous les modules nommés et non nommés observables, en particulier le module "Java.xml" dans la bibliothèque système JRE. Ce module exporte un paquet comme Java.xml.xpath.

De plus, vous avez xml-apis.Java sur le chemin d'accès aux classes, ce qui contribue à un autre ensemble de packages du même nom (Java.xml.xpath et amis). Celles-ci sont associées au module non nommé, comme votre propre code.

Cette situation viole l'exigence de "visibilité unique" définie dans JLS §7.4.3 (dernier paragraphe). En particulier, chaque nom de type qualifié Q.Id ( JSL §6.5.5.2 ) requiert que son préfixe Q soit un paquet uniquement visible (je ne tiens pas compte du cas des types imbriqués pour plus de simplicité). Ergo: le programme est illégal et doit être rejeté par les compilateurs.

Cela nous laisse avec une question et deux solutions:

(1) Question: Pourquoi javac accepte-t-il le programme?

(2) Solution: Si vous ajoutez module-info.Java à votre projet, vous pouvez contrôler via requiert que le module lu par votre projet, soit requires Java.xml; ou requires xml.apis; (où "xml.apis" est le nom de module automatique de "xml-apis- 1.4.01.jar).

(3) Solution: à moins de transformer votre projet en module, vous pouvez toujours éviter le conflit en excluant Java.xml de l'ensemble des modules observables. Sur la ligne de commande, cela se ferait avec --limit-modules. L'équivalent dans Eclipse est la boîte de dialogue "Détails de la modularité" , voir aussi l'onglet JDT 4.8 New & Noteworthy (recherchez l'onglet Contenu). Étant donné que Java.xml est implicitement requis via de nombreux autres modules observables par défaut, il peut être judicieux de tout pousser à l'exception de Java.base de droite ("modules explicitement inclus") à gauche ("modules disponibles") (et de les ajouter de manière sélective). les modules dont votre projet a besoin).

PS: Eclipse ne fournit toujours pas le message d'erreur idéal. Au lieu de "ne peut pas être résolu", il devrait en réalité indiquer: "Le paquet javax.xml.xpath est accessible à partir de plusieurs modules: javax.xml, <sans nom>.

PPS: Aussi étrange: pourquoi le fait de changer l’ordre entre JRE et un fichier jar sur le classpath (un tel ordre n’est pas supporté par javac ni JEP 261) modifie le comportement du compilateur.

EDITs:

  • Alex Buckley a confirmé que la situation donnée est illégale, malgré ce que dit javac.
  • Le message d'erreur Eclipse a été amélioré pour mentionner le vrai problème.
3
Stephan Herrmann

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

import org.w3c.dom.Element;

échouait à compiler dans Eclipse avec: The import org.w3c.dom.Element cannot be resolved

Malgré tout, en appuyant sur F3 (Déclaration ouverte) lors de cette importation, Eclipse a pu ouvrir la définition de l’interface - dans ce cas, sous xml-apis-1.4.01.jar.

Pendant ce temps, les versions de Maven direct fonctionnaient bien.

Dans ce cas, le correctif consistait à supprimer cette dépendance du pom.xml:

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

Ensuite, les erreurs de compilation dans Eclipse ont disparu. Suivant F3 a de nouveau montré l'interface Element - maintenant sous le module Java.xml, sous la bibliothèque système JRE sous le projet. Aussi la construction Maven est restée bien.

Cela ressemble à un problème lié à la résolution par Eclipse d'une classe trouvée à la fois dans un module JDK et dans un fichier .jar dépendant.

Fait intéressant, dans un environnement séparé, cette fois sous Eclipse 4.9.0 et JDK 11, tout va bien, avec ou sans la dépendance xml-apis:1.4.01.

0
df778899

Il s’agit plus d’une solution de contournement, mais mon expérience me permet de le résoudre en accédant à "Chemin de construction Java", onglet "Ordre et exportation" et en envoyant les "Dépendances Maven" au bas de la page "Bibliothèque système JRE").

0
Yossi