Eclipse не может найти связанные с XML классы после переключения пути сборки на JDK 10

Question

Я работаю над проектом Maven (branch platform-bom_brussels-sr7) в Eclipse. Когда я недавно пытался переключить Java Build Path для проекта на JDK 10, Eclipse build больше не может найти классы, такие как javax.xml.xpath.XPath, org.w3c.dom.Document или org.xml.sax.SAXException. Похоже, что затрагиваются только связанные с XML классы, в основном из зависимости Maven xml-apis-1.4.01.

Попытка сборки Maven из Eclipse работает без ошибок. Ctrl-LeftClick на одном из предположительно отсутствующих классов находит класс и открывает его в редакторе Eclipse. Кажется, пострадала только сборка Eclipse.

Я попробовал несколько вещей, но ничего не помогло. Я попробовал:

• Проект Чистый
• Различные версии Eclipse: кислород и фотон.
• Сам Eclipse работает с JDK 8 и JDK 10.
• Изменение уровня соответствия компилятора для проекта. Он строится с уровнем соответствия 8 и 10 по пути сборки JDK 8 и завершается неудачно для обоих с JDK 10 в пути сборки.

Answer 1

Я предполагаю, что проект, переносимый из Java 1.8, все еще не имеет module-info.java. Это означает, что вы компилируете код в «неназванном модуле».

Код в безымянном модуле «читает» все наблюдаемые именованные и безымянные модули, в частности, он читает модуль «java.xml» из системной библиотеки JRE. Этот модуль экспортирует пакет как java.xml.xpath.

Кроме того, у вас есть xml-apis.java на пути к классам, который предоставляет другой набор пакетов с такими же именами (java.xml.xpath и друзья). Говорят, что они связаны с неназванным модулем, как ваш собственный код.

Эта ситуация нарушает требование "уникальной видимости" , как определено в JLS §7.4.3 (последний абзац). В частности, каждое квалифицированное имя типа Q.Id ( JSL §6.5.5.2 ) требует, чтобы его префикс Q был уникально видимым пакетом (для простоты я игнорирую случай вложенных типов). Ergo: программа недопустима и должна быть отклонена компиляторами.

Это оставляет нам один вопрос и два решения:

(1) Вопрос: почему javac принимает программу?

(2) Решение: Если вы добавите module-info.java в свой проект, вы можете через контролировать , какой модуль читает ваш проект: requires java.xml; или requires xml.apis; (где "xml.apis") имя автоматического модуля "xml-apis-1.4.01.jar).

(3) Решение: Если не превратить ваш проект в модуль, вы все равно сможете избежать конфликта, исключив java.xml из набора наблюдаемых модулей. В командной строке это будет сделано с помощью --limit-modules. Эквивалентом в Eclipse является диалоговое окно «Сведения о модульности» , см. Также JDT 4.8 Новое и заслуживающее внимания (см. Вкладку Содержание ). Поскольку java.xml неявно требуется через множество других наблюдаемых по умолчанию модулей, может быть хорошей идеей подтолкнуть все, кроме java.base справа («явно включенные модули») влево («доступные модули») (и выборочно добавьте те модули, которые нужны вашему проекту).

PS: Eclipse по-прежнему не предоставляет идеального сообщения об ошибке, вместо «не может быть разрешено» оно должно фактически сказать: «Пакет javax.xml.xpath доступен из более чем одного модуля: javax.xml, .

PPS: Также странно: почему изменение порядка между JRE и jar на пути к классам (такое упорядочение не поддерживается ни javac, ни JEP 261) меняет поведение компилятора.

правок:

• Алекс Бакли подтвердил , что данная ситуация является незаконной, несмотря на то, что говорит Джавак. Ошибка в javac была поднята как JDK-8215739 . Эта ошибка была подтверждена за несколько месяцев до выпуска Java 12. По состоянию на 2019-06 гг. Было решено, что Java 13 будет поставляться без исправления.
• Eclipse error error был улучшен , чтобы упомянуть реальную проблему.
• В Eclipse 2019-06 пользовательский интерфейс, используемый для решения (3), был обновлен . Актуальную документацию можно найти в онлайн-справке .

Answer 2

Видели что-то очень похожее в Eclipse 4.8.0 и JDK 10. Например:

import org.w3c.dom.Element;

не удалось скомпилировать в Eclipse с: The import org.w3c.dom.Element cannot be resolved

Несмотря на это, нажав F3 (Открытое объявление) для этого импорта, Eclipse смог открыть определение интерфейса - в данном случае под xml-apis-1.4.01.jar.

Тем временем сборки из Maven direct работали нормально.

В этом случае исправлением было удаление этой зависимости из pom.xml:

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

Тогда ошибки компиляции в Eclipse растаяли. Следующий F3 снова показал интерфейс Element - теперь под модулем java.xml, под Системной библиотекой JRE в рамках проекта. Кроме того, сборка Maven осталась в порядке.

Это похоже на проблему с разрешением Eclipse класса, который он находит и в модуле JDK, и в зависимом файле .jar.

Интересно, что в отдельной среде, на этот раз в Eclipse 4.9.0 и JDK 11, все нормально, с зависимостью xml-apis:1.4.01 или без нее.

Answer 3

Это, как представляется, сообщается как Eclipse Bug 536928 . Возможно, если бы все проголосовали за это, они бы повысили приоритет.

Answer 4

Это скорее обходной путь, но, по моему опыту, его можно решить, перейдя на «Путь сборки Java», вкладку «Заказ и экспорт» и отправив «Зависимости Maven» вниз (так это ниже "Системной библиотеки JRE").

Answer 5

jdk 9+ внесены изменения, связанные с проектом Jigsaw. JDK был разбит на различные модули, и некоторые модули, связанные с javaee, jaxb и xml, больше не загружаются по умолчанию. Вы должны добавить их в свою сборку maven напрямую, вместо того, чтобы ожидать, что они будут в jre classpath. смотри ТАК вопрос