Решил тут поиграться с модулями, причем на реальном проекте и реальных зависимостях. Взял сразу Java 10. Без всякого описания module-info.java в принципе все работает, проблем не увидел. Решил сделать по фен шую, добавил эти модули. И как то геморроя смотрю многовато.
Как минимум куча ошибок вроде "Error:java: module junit reads package com.fasterxml.jackson.core.util from both protostuff.json and fst". На сторонних библиотеках и сторонних зависимостях. Что интересно, просто когда выполняю mvn clean install оно даже success показывает. И вот сижу и думаю, стоит эти модули использовать или нет? Или у меня просто руки кривые? Ибо вроде если такое фиксить — это нужно или править библиотеки, что хреновая идея. Или импортировать эти зависимости через fat-jat, что не всегда возможно, не удобно, куча движений, и в общем случае это тоже костыль.

Кто давно на девятке сидит или старше — эти модули стоят того, чтоб с ними корячиться? Или просто забиваете на модули и все по старинке?

Здравствуйте, elmal, Вы писали:

Сам не пользовался, чисто IMHO

Если проект это standalone java, а не библиотека для других проектов. То не стал бы. Не понимаю плюсов для проекта в этом случае

Если ты архитектора какой нибудь библиотеки для других комманд, то можно по пробовать более строго ограничить доступный API. Но, там пока все не перейдут опять же на более новую Java выгоды тоже не очевидны.

Здравствуйте, Tourist, Вы писали:

T>Если ты архитектора какой нибудь библиотеки для других комманд, то можно по пробовать более строго ограничить доступный API. Но, там пока все не перейдут опять же на более новую Java выгоды тоже не очевидны.
Да тут дело такое. На деле, я к нормальной модульности уже привык. Ибо 2 с половиной года пилю на Ceylon, где модульность просто шикарная (так говорю после того, как набил руку). У нас на Ceylon весьма серьезные проекты, до черта либ и т.д. Наступили на максимум граблей, научились обходить, за счет библиотек очень быстро делаем всякие прототипы с минимальным вхождением, в том числе новичками, у которых с программированием крайне хреново. Но вот текущая ситуация с Ceylon заставляет искать альтернативы. И текущее понимание ситуации, учитывая, что любой язык и платформа может загнуться, говорит что как минимум библиотеки должны быть строго с Java API. Чтоб их можно было юзать из любого JVM языка без проблем. Соответственно сейчас смотрю альтернативы в JVM мире, и как то очень все не нравится. Сравнимой с Ceylon модульности не предлагает никто. Я перевел один микросервис с Ceylon на Kotlin. Причем заюзал уже созданные наши библиотеки. Даже все заработало, и даже приемлемый синтаксис, не смотря на то, что наружу торчат цейлоновские коллекции и структуры. Даже времени не много потратил, и даже сам код походит на Ceylon. Но посмотрел на pom.xml — ну реально полный кабздец в сравнении. Соответственно хочется примерно того же функционала, что имею сейчас. Но чтоб без проблем мог юзать Java большей, чем восьмой, версии. Ибо на Java тоже есть значительное количество кода, которое критическое по производительности, и уже жить как минимум без var весьма противно. А такая фича, как value types обещает вообще полное счастье в будущем — можно будет еще перфоманс увеличить, без переписывания критичных частей на всякие Си или Rust.

И как результат, именно в долгосрочной перспективе хочу именно библиотеки писать чтоб они имели строго Java API. На Kotlin, ибо там как раз никакие SDK и коллекции не переписываются, и если он загнется, то ничего страшного, библиотеки можно без проблем юзать из любого JVM языка, у которого нет проблемы и интеропом . Хоть Scala, хоть даже Clojure. А если Ceylon воскреснет и наконец его продолжат пилить — то основной костяк делать на нем, ибо зарекомендовал себя весьма хорошо. Смотрю на долгий срок вперед, если что, предполагаю что именно JVM не загнется и с либами и инфраструктурой все будет так же хорошо (а то и лучше), как и сейчас. Но блин, посмотрел на ситуацию с модульностью в Java 9 — как то многовато граблей.

Ждать еще несколько лет, когда Java 9 станет мейнстимом чтоль? Ибо у меня такое впечатление, что модули Java 9 еще не скоро станут стандартом, соответственно большинство так и будет сидеть на Java 8 максимум.

Здравствуйте, elmal, Вы писали:

E>Здравствуйте, Tourist, Вы писали:

T>>Если ты архитектора какой нибудь библиотеки для других комманд, то можно по пробовать более строго ограничить доступный API. Но, там пока все не перейдут опять же на более новую Java выгоды тоже не очевидны.
E>Но посмотрел на pom.xml — ну реально полный кабздец в сравнении.
А можно поподробнее?

E>Ждать еще несколько лет, когда Java 9 станет мейнстимом чтоль? Ибо у меня такое впечатление, что модули Java 9 еще не скоро станут стандартом, соответственно большинство так и будет сидеть на Java 8 максимум.
Мне кажется, что никому они не здались и народ будет брыкаться до последнего и все делать по-старинке. Так, что думаю, что все останется так как есть и на module-info просто забьют. И по-традиции java все будет нормально работать как работает.

Здравствуйте, StanislavK, Вы писали:

E>>Но посмотрел на pom.xml — ну реально полный кабздец в сравнении.
SK>А можно поподробнее?
Поподробнее, пожалуйста.

Предположим я делаю новый проект. Из модулей service и data

projectdir
 -- source
     -- service
         -- module.ceylon
            run.ceylon   
     -- data
         -- module.ceylon
            run.ceylon

и содержимое module.ceylon:

module service "1.0.0" {
    import ceylon.http "1.3.3";
    import data "1.0.0";
}

module data "1.0.0" {
    shared import ceylon.random "1.3.3";
}

И все — весь проект (я код не указывал). При этом из коробки все зависимости будут скачаны из артифактория сразу при компиляции, проблемы могут быть только с корпоративным прокси. Все зависимости в одном месте, синтаксис компактный, ничего лишнего.

В случае с Java у меня будет отдельно описания модулей, с функционалом, практически аналогичным. Тут даже претензий нет. Но дополнительно будет куча, 3 штуки, pom.xml. Или аналогичных файлов других сборщиков. С иерархией, с указанием плагинов, необходимых чтоб это скомпилилось, с указанием всяких parent, с указанием версий, со всякими exclude для замены зависимостей. Если есть какой артифакт — я должен его сначала как зависимость указать в pom.xml, затем дополнительно в module-info.java. Причем, даже в трех местах наверно, в корневом pom я укажу версию, а в других или как минимум одном другом pom, относящемуся к конкретному модулю, буду еще снова указывать эту зависимость, но уже без номера версии. Реально кабздец, я от такого несколько отвык. Соответственно одно и тоже копипастится, можно ошибиться, и кроме информации о зависимостях у меня там еще до черта логики, вроде как мне компилять, каким компилятором. В результате файл бывает не слабенький по размеру, только из за зависимостей. Если брать другие билд тулы, а не maven, то дела обстоят не намного лучше.

В случае с ceylon вся информация о зависимостях сразу в наиболее читаемой форме, и о них практически не нужно волноваться. А если нужны на этапе сборки или еще на каком этапе дополнительная логика вроде кодогенерации перед компиляцией, всякая шаблонизация и т.д, подкладывание конфигов, сборка докер образа — вот именно эта логика и остается в билд тулах, и не размазывается с зависимостями. В результате можно даже написать универсальный корпоративный build.xml или еще что, который вообще без изменений тупо копипастится в пределах конторы среди всех проектов и среди всех разработчиков. Реально очень удобно.

И модульность — это только одна из фич, к которым привык, и которых ни черта нет у конкурентов.

Здравствуйте, elmal, Вы писали:

E>Поподробнее, пожалуйста.

E>Предположим я делаю новый проект. Из модулей service и data
E>

E>projectdir
E> -- source
E>     -- service
E>         -- module.ceylon
E>            run.ceylon   
E>     -- data
E>         -- module.ceylon
E>            run.ceylon  
E>

E>и содержимое module.ceylon:
E>

E>module service "1.0.0" {
E>    import ceylon.http "1.3.3";
E>    import data "1.0.0";
E>}
E>

E>

E>module data "1.0.0" {
E>    shared import ceylon.random "1.3.3";
E>}
E>

E>И все — весь проект (я код не указывал). При этом из коробки все зависимости будут скачаны из артифактория сразу при компиляции, проблемы могут быть только с корпоративным прокси. Все зависимости в одном месте, синтаксис компактный, ничего лишнего.
maven примерно то же самое, только он правда на xml что выглядит гадко, но к этому привыкаешь быстро.

E>В случае с Java у меня будет отдельно описания модулей, с функционалом, практически аналогичным. Тут даже претензий нет. Но дополнительно будет куча, 3 штуки, pom.xml.
В вашем примере — 2 файла, иметь 3 в случае с мэйвеном не так уж и страшно.

E>Или аналогичных файлов других сборщиков. С иерархией, с указанием плагинов, необходимых чтоб это скомпилилось, с указанием всяких parent, с указанием версий, со всякими exclude для замены зависимостей. Если есть какой артифакт — я должен его сначала как зависимость указать в pom.xml, затем дополнительно в module-info.java. Причем, даже в трех местах наверно, в корневом pom я укажу версию, а в других или как минимум одном другом pom, относящемуся к конкретному модулю, буду еще снова указывать эту зависимость, но уже без номера версии. Реально кабздец, я от такого несколько отвык.
Не, что-то там не то
exclude надо упоминать только если транзитивные зависимости какие-то не такие. Но это придется упоминать в любом туле? Или я что-то не понимаю?
module-info.java — мне кажестя на это надо просто болт забить.
Указывать конктетную версию в главном поме — это дело опциональное и исключительно для того, чтобы по проекту не плодились разные версии зависимости. Если не хотите этого делать — дело ваше, мэйвен не настаивает.

E>Соответственно одно и тоже копипастится, можно ошибиться, и кроме информации о зависимостях у меня там еще до черта логики, вроде как мне компилять, каким компилятором. В результате файл бывает не слабенький по размеру, только из за зависимостей. Если брать другие билд тулы, а не maven, то дела обстоят не намного лучше.
На самом деле все не так плохо. Мэйвен просто из-за xml-я несколько многословен. Копи-паста нет, если все правильно делать.
Есть еще варант — gradle, там практически такой же синтаксис как в вашем прмере.

E>В случае с ceylon вся информация о зависимостях сразу в наиболее читаемой форме, и о них практически не нужно волноваться. А если нужны на этапе сборки или еще на каком этапе дополнительная логика вроде кодогенерации перед компиляцией, всякая шаблонизация и т.д, подкладывание конфигов, сборка докер образа — вот именно эта логика и остается в билд тулах, и не размазывается с зависимостями.
У мэйвена так же? Я к тому что файл-то всегда один, независимо от тула? Согласен, что в maven файл не такой лаконичный, но это вся разница.

E>В результате можно даже написать универсальный корпоративный build.xml или еще что, который вообще без изменений тупо копипастится в пределах конторы среди всех проектов и среди всех разработчиков. Реально очень удобно.
В мэйвене тоже можно. В качестве примера посмотрите как spring-boot тянет свои зависимоти и плагины в проект.

E>И модульность — это только одна из фич, к которым привык, и которых ни черта нет у конкурентов.
А что именно имеется ввиду под модульностью?

Я к чему это все. Мэйвен очень гадок в плане иснтаксиса, но это реально единственная гадкая вещь в этой туле.
Есть еще люди, которые жалуются, что он мол не гибкий и пользуют gradle. Но с gradle надо быть аккуратным — часто народ его не понимает (так же как они не поняли до того maven) и пишет весь билд ручками, старательно обходя все фичи самого тула.

Здравствуйте, StanislavK, Вы писали:


SK>module-info.java — мне кажестя на это надо просто болт забить.
Угу. Как и забить на нормальную модульность, о чем я и говорю . Ведь фича прекрасная на деле. Только ее нужно было делать с самого начала. А сейчас столько легаси без этого, да и либ без этого, что хрен на эту модульность перейдешь. Плюс некомфортно (в чем некомфортно, я указал), даже если и не легаси. Геморроя получается больше, чем плюсов. Тоже попробовал, и тоже хочется забить и делать все по старинке. Но новые то вещи хотелось бы по фен шую делать.

SK>>module-info.java — мне кажестя на это надо просто болт забить.
E>Угу. Как и забить на нормальную модульность, о чем я и говорю . Ведь фича прекрасная на деле. Только ее нужно было делать с самого начала. А сейчас столько легаси без этого, да и либ без этого, что хрен на эту модульность перейдешь. Плюс некомфортно (в чем некомфортно, я указал), даже если и не легаси. Геморроя получается больше, чем плюсов. Тоже попробовал, и тоже хочется забить и делать все по старинке. Но новые то вещи хотелось бы по фен шую делать.

А разве Мавен не умеет генерировать модули для Явы исходя из своих помов? Было бы логично.

Здравствуйте, bzig, Вы писали:

SK>>>module-info.java — мне кажестя на это надо просто болт забить.
E>>Угу. Как и забить на нормальную модульность, о чем я и говорю . Ведь фича прекрасная на деле. Только ее нужно было делать с самого начала. А сейчас столько легаси без этого, да и либ без этого, что хрен на эту модульность перейдешь. Плюс некомфортно (в чем некомфортно, я указал), даже если и не легаси. Геморроя получается больше, чем плюсов. Тоже попробовал, и тоже хочется забить и делать все по старинке. Но новые то вещи хотелось бы по фен шую делать.

B>А разве Мавен не умеет генерировать модули для Явы исходя из своих помов? Было бы логично.

Действительно, не умеет. По ссылке причины, но, мне кажется, надуманные

https://www.sitepoint.com/maven-cannot-generate-module-declaration/

E>Только ее нужно было делать с самого начала.

Ты простой такой. В Цейлоне получилось так сделать, потому что репозитории Мавена уже были доступны и в них лежало всё. Когда Яву пилить начинали, откуда бы закачивались все эти зависимости?

Здравствуйте, StanislavK, Вы писали:

SK>Я к чему это все. Мэйвен очень гадок в плане иснтаксиса, но это реально единственная гадкая вещь в этой туле.
SK>Есть еще люди, которые жалуются, что он мол не гибкий и пользуют gradle. Но с gradle надо быть аккуратным — часто народ его не понимает (так же как они не поняли до того maven) и пишет весь билд ручками, старательно обходя все фичи самого тула.

Я смысла в gradle как раз не понимаю. Мавен же есть, он гораздо более распространён, может всё то же самое, расширений для него написана уйма, чего ещё надо-то? Ну, тяжеловесно, так и задачи такие здесь, тяжеловесные. Сложные задачи не решаются простыми способами.

Здравствуйте, elmal, Вы писали:

E>Кто давно на девятке сидит или старше — эти модули стоят того, чтоб с ними корячиться? Или просто забиваете на модули и все по старинке?
Рано сразу по нескольким причинам. Во-первых, имхо все ждут 11 этой осенью — если начинать такую масштабную миграцию, то сразу на хорошо пропатченной LTS версии и после обратной связи от early adopters. Во-вторых, нужно дождаться готовности ключевых библиотек или их форков: SLF4J например даже до беты не добрался еще, а еще должны стать модульными Guava, Apache Commons, Jackson и конечно крупные фреймворки типа Hibernate и Spring. Нужно увидеть, как с модульностью работают какие-нибудь Tomcat и Netty (что там с безопасностью), как взаимодействуют OSGi контейнеры и т.д. Нужна нормальная поддержка инструментов (и мб следующая версия POM.xml с измененным форматом описания зависимостей — чтобы module-info генерировался, и поддержка этой версии в IDE). По всему выходит еще года два-три, а вот потом заживем (там и value types уже будут небось).

Здравствуйте, elmal, Вы писали:

E>Угу. Как и забить на нормальную модульность, о чем я и говорю . Ведь фича прекрасная на деле. Только ее нужно было делать с самого начала. А сейчас столько легаси без этого, да и либ без этого, что хрен на эту модульность перейдешь. Плюс некомфортно (в чем некомфортно, я указал), даже если и не легаси. Геморроя получается больше, чем плюсов. Тоже попробовал, и тоже хочется забить и делать все по старинке. Но новые то вещи хотелось бы по фен шую делать.

А что ты вкладываешь в слово "модульность"? Я не знаком с цейлоном, но в чем его отличие от модуля в мавене?

Java 9 добавляет новые возможности по инкопсуляции классов в джарниках ака "модули", но это отдельная тема и я вижу пока какую то путаницу в терминах тут. Модули есть и в мавене.

Если тебе нужно просто разбить проект по модулям, вынести модель к примеру в один джарник, сервисы для работы с моделью в другой джарник\модуль. То чем мавен с реактором не подходит?

Здравствуйте, elmal, Вы писали:

E>Решил тут поиграться с модулями, причем на реальном проекте и реальных зависимостях. Взял сразу Java 10. Без всякого описания module-info.java в принципе все работает, проблем не увидел. Решил сделать по фен шую, добавил эти модули. И как то геморроя смотрю многовато.
Нафиг эти модули. Проблем не решают никаких, зато геморроя создают дофига.

Здравствуйте, elmal, Вы писали:

E>Кто давно на девятке сидит или старше — эти модули стоят того, чтоб с ними корячиться? Или просто забиваете на модули и все по старинке?

Я жду Java 11, LTS-версию, потому как наш энтерпрайз пока не готов обновлять JDK каждые полгода.

Модули выглядят интересной возможностью. Немного поигрался. Пока не используем (сидим на JDK 8), но, думаю будет полезно чтоб предотвратить возможность дерганья внутренностей компонентов. На данный момент — иногда случается, что человек пилит какую-то свою фичу и вызывает другие компоненты не так, как задумано, а так, как ему удобнее. Стадия код-ревью для этого это уже немножко поздно — код человек, конечно, поправит, но он уже потратил время чтоб написать этот код, а теперь нужно потратить еще время, чтоб переписать так, как просят. С модулями можно будет ограничить возможность доступа к потрохам компонентов.

Здравствуйте, Artem Korneev, Вы писали:

AK>Здравствуйте, elmal, Вы писали:

E>>Кто давно на девятке сидит или старше — эти модули стоят того, чтоб с ними корячиться? Или просто забиваете на модули и все по старинке?

AK>Я жду Java 11, LTS-версию, потому как наш энтерпрайз пока не готов обновлять JDK каждые полгода.

AK>Модули выглядят интересной возможностью. Немного поигрался. Пока не используем (сидим на JDK 8), но, думаю будет полезно чтоб предотвратить возможность дерганья внутренностей компонентов. На данный момент — иногда случается, что человек пилит какую-то свою фичу и вызывает другие компоненты не так, как задумано, а так, как ему удобнее. Стадия код-ревью для этого это уже немножко поздно — код человек, конечно, поправит, но он уже потратил время чтоб написать этот код, а теперь нужно потратить еще время, чтоб переписать так, как просят. С модулями можно будет ограничить возможность доступа к потрохам компонентов.

Это и сейчас можно, выставляй наружу интерфейс

Здравствуйте, Tourist, Вы писали:

T>А что ты вкладываешь в слово "модульность"? Я не знаком с цейлоном, но в чем его отличие от модуля в мавене?
T>Java 9 добавляет новые возможности по инкопсуляции классов в джарниках ака "модули", но это отдельная тема и я вижу пока какую то путаницу в терминах тут. Модули есть и в мавене.
А я и говорю про девятку. В мавене есть артифакты, а не модули. Модуль кроме всего прочего описывает публичное API. И именно модуль еще и описывает зависимость от других модулей. То есть сделали в девятке все довольно неплохо, лично мне понравилось. Но пока тулинг хромает и общая инфраструктура еще не созрела. На деле, допиливать нужно уже не Java, а мавен и подобные средства. Чтоб информацию о зависимостях брались автоматом из описания модулей, заставляя указывать только информацию о версиях. Только не уверен я, что в обозримом будущем допилят нормально.

Здравствуйте, bzig, Вы писали:

B>Это и сейчас можно, выставляй наружу интерфейс

Что делать, когда скрыть нужно даже сам интерфейс?

Здравствуйте, elmal, Вы писали:

E>Здравствуйте, Tourist, Вы писали:

T>>А что ты вкладываешь в слово "модульность"? Я не знаком с цейлоном, но в чем его отличие от модуля в мавене?
T>>Java 9 добавляет новые возможности по инкопсуляции классов в джарниках ака "модули", но это отдельная тема и я вижу пока какую то путаницу в терминах тут. Модули есть и в мавене.
E>А я и говорю про девятку. В мавене есть артифакты, а не модули. Модуль кроме всего прочего описывает публичное API. И именно модуль еще и описывает зависимость от других модулей. То есть сделали в девятке все довольно неплохо, лично мне понравилось. Но пока тулинг хромает и общая инфраструктура еще не созрела. На деле, допиливать нужно уже не Java, а мавен и подобные средства. Чтоб информацию о зависимостях брались автоматом из описания модулей, заставляя указывать только информацию о версиях. Только не уверен я, что в обозримом будущем допилят нормально.

Так в цейлоне тоже можно было в модули описывать публичное API доступное другим модулям?

В Java ограничить API библиотеки и скрыть внутрености и сейчас доступно, но не очень удобно и в Java есть кучу иструментов обойти эти ограничения наложенные разработчиком библиотеки.

Что вам нужно то в итоге? Модульность есть и легко делаеться на мавене. Ограничить API модуля можно используя разные патерны в Джаве любой версии.

Можете называть модули в мавене артефактами, но они все равно остануться модулями на которые хорошо разбиваються проекты, выстраиваються зависимости между модулями.

B>>Это и сейчас можно, выставляй наружу интерфейс

AK>Что делать, когда скрыть нужно даже сам интерфейс?

package private

Правда, у меня складывается впечатление, что ты не от случайного использования защищаешься, а от злонамеренного.