проблема с модулями в жаве

Не надо пользоваться модулями в жаве, они не готовы для продакшна. Удали файл module-info.java и не добавляй их больше.

Ты ещё обратно на восьмую яву посоветуй перейти.

Это вынужденная мера. Я старый мод для майнкрафта портирую на последнюю версию. Вот этот https://www.microsoft.com/en-us/research/project/project-malmo/. В майнкрафте своя система подгрузки аддонов, пишут без модулей тоже не будет работать.

При чём тут восьмая ява и модули? Фреймворки их не поддерживают. Спринг бут их не поддерживает. Оракловый хелидон их не поддерживает (хотя казалось бы). Некоторые популярные библиотеки с ними тупо не совместимы и особо не собираются. Я это пишу как человек, который искренне потратил пару дней на попытки их включить.

Если ты фреймворками пользоваться не собираешься и готов отказываться от библиотек, которые не работают с модулями - ну ок. Но то такое.

Ну тогда настраивай module-info.java если ты ничего не путаешь. Вот тебе мой пример, который я таки заставил работать со скрипом:

module kz.mycoolapp {
    requires java.logging;
    requires java.xml;
    requires java.xml.bind;

    requires com.google.common;
    requires io.helidon.common;
    requires io.helidon.config;
    requires io.helidon.health;
    requires io.helidon.health.checks;
    requires io.helidon.logging.common;
    requires io.helidon.media.jsonb;
    requires io.helidon.webclient;
    requires io.helidon.webserver;
    requires org.apache.santuario.xmlsec;
    requires org.apache.wss4j.common;
    requires org.apache.wss4j.dom;

    opens kz.mycoolapp to org.eclipse.yasson;
    opens kz.mycoolapp.bip_sync to java.xml.bind;
    opens kz.mycoolapp.rpn.get_person_by_fio_iin to java.xml.bind;
    opens kz.mycoolapp.erdb to java.xml.bind;
}

Какая тут релевантная строчка для неименованых модулей?

Для них разве можно писать requires?

Ладно, попробую без модулей завести, может так проще будет.

Нельзя. Для unnamed надо флагом в командной строке указывать разрешения. Что-то вроде --add-exports java.xml/com.sun.org.apache.xerces.internal.impl.dtd=ALL-UNNAMED А лучше сделать его в named. У тебя по-хорошему не должно быть unnamed модулей.

Сколько лет уже не готовы?

Очевидно, что Spring отстал от мейнстрима. Для него модули Java никогда не будут готовы.

Ну как вышла жава 9 в 2017, так и не готовы, 4 с лишним года уже выходит. Вот последний комментарий от спринг бута:

I’m going to close this one as, at this time, we don’t plan to do anything more in this area. We can perhaps revisit this in the future if the ecosystem starts to move towards Jigsaw and Spring Framework moves beyond automatic modules.

Надо попробовать, может последние версии уже работают с модулями. Но пока оно не начнёт генериться в официальных стартерах, это всё будет из разряда на свой страх и риск.

Spring и есть мейнстрим

Мейнстрим это Java EE 8 и её реализации в виде эталонного Eclipse GlassFish и WildFly.

если бы они не были готовы в каждой жарке не было бы дескрипторов module-info.java для соответствия модульному подходу. Тут скорее определенным проектам вполне себе живется и без переведения своего дерева исходных кодов в плоскость ничего не дающих модулей. Например javafx в лице openjfx понавтыкала в каждую жарку по дескриптору, javax.json туда же, вся стандартная рантайм богадельня имеет дескрипторы и т.д. Я хз о чем Легионер рассказывает, но сейчас не так много осталось проектов которые хотя бы минимально не расписали дескрипторы.

Можно подумать, Java EE 8 модуляризована (если забыть о том, что оно сдохло не родившись)

Eclipse GlassFish

Оно изо всех сил мертво

JSR 376 (модульность Java) относится к JDK, а не к рализации Java EE.

Да-да, вот уже несколько лет всё не могут закопать и выходят новые версии. Интересно, кто ими пользуется? Ну конечно же не те, кому мил Spring Boot. Продолжайте наблюдения и глотание слюней.

Не смешно даже.

Как пример мажорного бага, который забивали пофиксить 3.5 года: https://github.com/eclipse-ee4j/glassfish/issues/2135

Чёт не то скинул, мдэ

https://github.com/eclipse-ee4j/glassfish/issues/21314

Это в идеальном мире. За который я выступаю так же как и ты.

Но это наш поехавший манямирок, на который всем срать.

Что это дает на деле, в том виде в котором оно есть?

Обьяснение прошу расписать в долларах, до и после. Выглядит как танцы с бубном и трата времени

Что это дает на деле, в том виде в котором оно есть?

Например одна либа не сможет залезть в ресурсы другой либы (поэтому, к примеру, flyway принципиально не может работать с жава модулями в текущем виде). Одна либа не сможет рефлексией расковырять другую либу, если только ей это не разрешат.

В общем куча нетривиальных способов получить Error во имя чистоты концепций.

В целом по-моему это больше для защиты кишков JVM делалось. Чтобы прекратили туда лазить. И разработчики наконец-то могли начать что-то менять не боясь поломать какой-нибудь ломбок.

Из полезного - можно убрать public-классы из пакета impl своей либы. А то щас по сути в любой либе в public лежат куча классов, которые на самом деле не подразумевались как public.

Ok, изоляция.

Я думал речь о уменьшении потребления ресурсов, модуляризация JRE

Ну в теории jlink/jpackage вроде как лучше работают с модульными приложениями, но детали я не знаю, почему, насколько лучше и тд. Предполагаю, что они могут положить в образ не всю JRE, а только нужные части.

Ну такие цели тоже типа преследовались, но по большому счету модули все-таки пшик. Дескриптор дали, дали возможность декларативно расписать кто, что как импортирует, что экспортирует, от чего зависит, от чего зависит транзитивно, дали директивы для ограничения попыток рефлексии и т.д. Перетряхнули дерево исходных текстов реализации джавы просто чтобы теперь оно отражало идею наличия модулей, перетряхнули jre и нарезали на jmod пакеты вместо jar, наколупали jlink и возможность им делать кастомные рантаймы под софт с генерацией скрипта лончера под целевую платформу, раньше это делали руками, теперь есть jlink. Но при этом добавили ключи компиляции которые форсят если надо все эти описанные ограничения в дескрипторах и дают возможность добраться до тех классов реализации которые считаются теперь внутренними не для использования прикладным кодом. Короче инкапсуляция как была дырявая так и осталась, только теперь надо явно показать свои намерения через ключи компиляции и через правильно написанный дескриптор если вы собрались делать что-то, что все эти jep и jsr просят вас не делать.

Конкретно в моём случае можно забить, там загрузчик jar-файлов в рантайме генерит модули, из-за чего не работает эклипсовский javax. Выходит да, модули пока не удобны и грейдл недалеко от cmake ушёл.

Советую перейти на седьмую яву.

Вообще всем заинтересованным, советую почитать вот эту статейку и все перечисленные в ней jep и jsr до полного просветления и лучистости.