Почему пакеты и модули являются отдельными понятиями в Java 9?

Java 9 будет иметь модули в дополнение к пакетам. Обычно языки имеют один или другой. И большинство программистов воспринимают два термина как синонимы. Модули строятся поверх пакетов, рассматривая их как примитивы. Композитный шаблон предлагает обращаться с примитивами и композитами равномерно. Иначе произойдут плохие вещи. Например, посмотрите на проект Valhalla, где они пытаются модифицировать общий супертип для примитивного (значения) и ссылочного типов.

Являются ли модули и пакеты семантически отдельными понятиями? То есть разумно иметь и то и другое для любого языка (разделение интересов). Или Java должна иметь и то, и другое как дань обратной совместимости?

Зачем вводить новую концепцию, а не дополнять существующую?

JSR 376 : «модульная система платформы Java», реализованная в рамках проекта Jigsaw .

По данным СОТМС

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

JLS тщательно избегает определения того, что представляет собой пакет . Из Википедии :

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

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

Термин пакет иногда используется вместо модуля (как в Dart, Go или Java). В других реализациях это отдельная концепция; в Python пакет представляет собой набор модулей, в то время как в следующей версии Java 9 планируется введение новой концепции модуля (набор пакетов с расширенным контролем доступа).

Понятие модуля отличается от конкретизации этого понятия.

У Java всегда были модули. Метод - это модуль, так же как класс и пакет. Модуль - это единица организации, в которой скрыты внутренние детали и которая взаимодействует с другими модулями по согласованным договорам. Например, метод является модулем, потому что он имеет скрытые внутренние компоненты (код и локальные переменные) и контракт (параметры и тип возвращаемого значения). Модули могут быть составлены из модулей более низкого уровня, например, классы содержат методы.

В ядре Java (до 9) отсутствует развертываемый модуль. Все вышеперечисленные виды модулей не являются развертываемыми блоками, которые можно копировать. В Java есть развертываемый артефакт, называемый файлом JAR, но это не модули, потому что у них нет инкапсуляции или контракта: во время выполнения файлы JAR исчезают, все объединяются в один «путь к классам».

В 1998 году OSGi решила проблему отсутствия развертываемых модулей с помощью концепции «связки». Это физически файлы 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 :

Управление зависимостями:

Maven рекомендует использовать центральный репозиторий JAR-файлов и других зависимостей. Maven поставляется с механизмом, который клиенты вашего проекта могут использовать для загрузки любых JAR-файлов, необходимых для построения вашего проекта, из центрального JAR-репозитория, очень похожего на Perl CPAN. Это позволяет пользователям Maven повторно использовать JAR-файлы в разных проектах и ​​стимулирует обмен данными между проектами для обеспечения решения проблем обратной совместимости.

Теперь поговорим о будущем, как будто я был там

Как упоминалось на этой странице , другие языки (такие как Perl) имеют репозитории пакетов (например, CPAN ). Это возрастающая тенденция (я говорю, потому что я чувствую, что это так, без каких-либо убедительных доказательств), в течение последнего десятилетия или около того. Такие инструменты, как Руби драгоценных камней , Пайтона PyPi , и менеджер пакетов Node ( npm) построить на этом , чтобы обеспечить последовательный способ настройки среды (либо разработки, сборки, тестирования, или во время выполнения, и т.д.) с правом материал (пакеты, модули, драгоценные камни, штуковины и т. д.). Идея (я чувствую) была « заимствована » из дистрибутивных систем Linux®, таких как Debian apt , RedHat'srpmи т. д. (Хотя, очевидно, эволюционировало хотя бы одно поколение, и все эти вещи стали приятнее.)

Java модули , хотя они не обязательно добавить , что вы не можете сделать уже, грим набор инструментов для зависимостей / управления пакетами и автоматизированных сред сборок все гораздо проще. Делает ли это модули «лучше», я отказываюсь говорить. :П