Чому пакети та модулі - це окремі поняття в Java 9?

У Java 9 будуть додатково встановлені модулі. Зазвичай мови мають те чи інше. І більшість програмістів сприймають два терміни як синоніми. Модулі побудовані поверх пакетів, трактуючи їх як примітиви. Складений малюнок пропонує ставитись до примітивів та композитів рівномірно. Інакше трапляться погані речі. Наприклад, подивіться на проект Valhalla, де вони намагаються доопрацювати загальний супертип для примітивних (значення) та еталонних типів.

Чи модулі та пакети представляють семантично окремі поняття? Значення це має сенс мати як для будь-якого мови (поділ проблем). Або Java має бути обома як данина відсталому сумісності?

Навіщо вводити нову концепцію замість розширення існуючої?

JSR 376 : "Система модуля платформи Java", реалізована в рамках проекту Jigsaw .

За даними SOTMS

Модуль - це іменований, самоописуючий набір коду та даних. Його код організований у вигляді набору пакетів, що містять типи, тобто класи Java та інтерфейси; її дані включають ресурси та інші види статичної інформації.

JLS обережно уникає визначення того, що таке пакет . З Вікіпедії :

Пакет Java - це метод організації класів Java в простори імен, схожих на модулі Modula, що забезпечують модульне програмування на Java.

Я знаю, що цитування Вікіпедії - це погана практика, але вона відображає загальне розуміння. Від входу на модульному програмуванні:

Термін пакунок іноді використовується замість модуля (як у Dart, Go або Java). В інших реалізаціях це окрема концепція; у Python пакет - це сукупність модулів, тоді як у майбутньому Java 9 планується впровадження нової концепції модуля (колекція пакетів з розширеним контролем доступу).

Поняття модуля відрізняється від конкретизації цього поняття.

У Java завжди були модулі. Метод - це модуль, клас - це також пакет. Модуль - це одиниця організації, в якій приховані внутрішні деталі, і яка спілкується з іншими модулями за допомогою узгоджених контрактів. Наприклад, метод - це модуль, оскільки він має приховані внутрішні (код та локальні змінні) та контракт (параметри та тип повернення). Модулі можуть складатися з модулів нижчого рівня, наприклад, класи містять методи.

Чого не вистачає в ядрі Java (до 9), це модуль розгортання . Всі перераховані вище види модуля не є розгортаються одиницями, які можна скопіювати навколо. У Java є артефакт, що розгортається, називається файлом JAR, але це не модулі, оскільки вони не мають інкапсуляції чи контракту: під час виконання файли JAR зникають, і всі вони об'єднуються в один "класний шлях".

OSGi вирішила відсутність модулів, що розгортаються в 1998 році, з концепцією "розшарування". Це фізично файли JAR і вони містять пакети, але OSGi визначає додаткові метадані разом із системою виконання для підтримки інкапсуляції та контрактів на цьому рівні.

Java 9 вирішує відсутність модулів, що розгортаються, аналогічно OSGi. Можливо, це було зовсім непотрібно, оскільки OSGi існує і працює, але це зовсім інша дискусія ...

На жаль, Java 9 замулює води, називаючи нову концепцію модуля просто "модулем". Це не означає, що методи, класи та пакети перестають бути модулями! "Модуль" J9 - це ще одна інстанція концепції модуля . Як і пакети OSGi, модулі J9 складаються з пакетів, і це фізичні артефакти (зазвичай файли JAR знову), які можна копіювати навколо. Система виконання їх розуміє і повторює.

Резюме: так, модулі та пакети J9 - це семантично окремі поняття. Очевидно, що Java повинна зберегти існуючу концепцію пакету для зворотної сумісності. Зауважте, що слово "пакет" в Java використовується зовсім інакше, ніж в інших мовах або в системах управління пакетами, такими як RPM. Нові модулі J9 (і пакети OSGi) набагато більше схожі на пакети в RPM, ніж коли-небудь пакети Java.

Дозвольте мені загрожувати відповіддю, хоча велика частина цього може бути припущеннями / розщепленням волосся / відшаровування тощо.

Вони однакові? Ну так ^_і ні

З цієї статті JavaWorld про "Модульність у Java 9" :

Пакети як модульне рішення

Пакети намагаються додати рівень абстракції до ландшафту програмування Java. Вони надають засоби для унікальних просторів кодування імен та конфігураційних контекстів. Однак, на жаль, пакетних конвенцій легко обійти, що часто призводить до обстановки небезпечних з'єднань під час збирання.

Як натякнув @ user2418306 (OP) , " модулі - це пакети зроблені правильно " . Модулі та пакети в Java (очевидно, як у Java 9) є (як запитує ОП) семантично те саме. Тобто це колекції попередньо складених байт-кодів JVM, з іншими метаданими - по суті , це бібліотеки .

Ну яка різниця?

Однак різниця полягає у метаданих всередині кожного з них. Java- packageманіфести, або JAR-маніфести, розробники бібліотек не підтримуються часто, а також не надають жодного впевненого контракту щодо того, що надає JAR / пакет. Як пояснено тут (стаття JavaWorld знову) :

Файли JAR недостатньо модульні?

Файли JAR та середовище розгортання, в яких вони працюють, значно вдосконалюються для багатьох наявних у встановленому порядку умов розгортання. Але файли JAR не мають внутрішньої унікальності, крім рідко використовуваного номера версії, який прихований у маніфесті .jar. Файл JAR та необов'язковий маніфест не використовуються як умови модульності в середовищі виконання Java. Тож назви пакетів класів у файлі та їхня участь у класному шляху є єдиними частинами структури JAR, які надають модульність середовищу виконання.

Шум про інші мови / середовища тощо

Ще однією областю, що обговорюється в цій статті, є такі системи, як Maven , які керують залежностями для вас в рамках процесу збирання. З цієї сторінки на сайті Apache Maven :

Управління залежністю:

Мейвен заохочує використання центрального сховища JAR та інших залежностей. Maven оснащений механізмом, який клієнти вашого проекту можуть використовувати для завантаження будь-яких JAR, необхідних для побудови вашого проекту, з центрального сховища JAR, подібно до CPAN Perl. Це дозволяє користувачам Maven повторно використовувати JAR у проектах та заохочує спілкування між проектами, щоб забезпечити вирішення проблем із сумісністю.

Тепер поговорити про майбутнє так, ніби я там був

Як зазначалося на цій сторінці , інші мови (наприклад, Perl) мають сховища пакетів (наприклад, CPAN ). Це тенденція, що зростає (я кажу, тому що я відчуваю, що це подобається, без жодних чітких доказів) протягом останнього ~ десятиліття або близько того. Інструменти, такі як дорогоцінні камені Ruby , PyPhon PyPi та менеджер пакетів Node ( npm) , надходять на це, щоб забезпечити послідовний спосіб налаштування середовища (або розробки, складання, тестування, або часу виконання тощо) на потрібні речі (пакети, модулі, дорогоцінні камені, штучки тощо). Ідея (я відчуваю) була " запозичена " з дистрибуційних систем Linux®, таких як Debian Apt , RedHat'srpmі т. д. (Хоча, очевидно, еволюціонувало щонайменше одне покоління, і зробило ці речі приємнішими.)

Java- модулі , хоча вони не обов'язково додають те, що ви вже не можете зробити, полегшують інструменти для залежностей / управління пакетами та автоматизованих середовищ збирання НАБАГО . Чи це робить модулі «кращими», я не хочу сказати. : P