R-Style Softlab | Зачем Java стал модульным?
Сергей Хоменко, ведущий программист департамента аналитических систем, R-Style Softlab
Программисты на Java хорошо знают одну его особенность: для использования кода, написанного на этом языке, всегда требуется наличие платформы (так называемой среды исполнения Java Runtime Environment). Из-за монолитности платформы до Java 9 любая программа содержала в себе большое количество неиспользуемых классов самой платформы. Теперь же ситуация изменилась — в Java «из коробки» поддерживается модульная архитектура, и первое место, где она используется, — пакеты Java Development Kit (JDK).
На протяжении уже многих лет Java остается самым популярным языком программирования в мире, о чем, в частности, свидетельствуют данные рейтинга TIOBE (рис. 1).
Рис. 1. Топ-10 языков программирования в рейтинге TIOBE, опубликованном в апреле 2018 г.
И неудивительно, ведь он обеспечивает обратную совместимость почти на 100% (что очень важно для корпоративных решений), предоставляет программистам широкие возможности, независим от платформы (написанные на нем программы могут работать в любой среде), обладает огромным сообществом пользователей.
Рис. 2. Самые ожидаемые новые возможности в Java 9 (схема позаимствована из статьи Alex Zhitnitsky «What Java 9 features are developers yearning for most?», опубликованной на портале JAXenter)
Сообщество, в свою очередь, прилагало усилия для внедрения модульности в программы, написанные на Java, — например, в OSGi или JBoss Modules. Однако официальных инструментов от Sun/Oracle не выпускалось никогда, а попыток разбить на модули саму JDK не было вовсе. До недавнего времени…
Судьбоносной датой можно считать 21 сентября 2017 года — в этот день Oracle выпустила первый стабильный релиз Java 9, в котором была реализована поддержка модульности. Это сделало платформу более гибкой, производительной и защищенной за счет разбиения JDK на модули и внедрения возможности использования модульной архитектуры в создаваемых решениях.
Преимущества модульности в Java
Кроме прочих нововведений, таких как исправление ошибок, изменение/улучшение API, изменение в GC, поддержка HTTP/2 клиента и, конечно же, обновленная консоль, ключевой особенностью нового релиза стало развитие проекта Jigsaw в Java Platform Module System (JPMS).
Перечислю основные преимущества, которых удалось добиться внедрением модульности:
- Надежная (однозначная) конфигурация приложения. Механизм «модульности» предоставляет способ однозначно определить зависимости между модулями. Такие зависимости могут быть распознаны и во время компиляции кода, и в процессе его исполнения. Таким образом, система может в любой момент времени определить, какие наборы модулей необходимы для работы приложения в целом.
- Усиленная инкапсуляция. Пакеты в модулях доступны извне только в том случае, если модуль явно их экспортировал. Но даже тогда другой модуль не сможет использовать такие пакеты, поскольку для этого нужно явно выразить это намерение.
- Масштабируемая Java-платформа. Ранее, чтобы запустить Java-приложение, нужна была среда Java Runtime Environment (JRE) целиком, даже если это приложение все лишь выводило на экран сакраментальную фразу «Hello World». Теперь платформа состоит из набора модулей (я насчитал 95 штук), и разработчик может решить сам, какие из них понадобятся его приложению.
- Повышенная целостность платформы. До выхода Java 9 была возможность использовать любые классы JDK. Теперь же, учитывая более сильную инкапсуляцию при реализации модулей, из которых состоит и JDK, использование классов, описывающих детали реализации за пределами модуля, становится фактически невозможным.
- Рост производительности. Как известно, виртуальная машина Java (JVM) использует различные механизмы оптимизации. Производители утверждают, что эти механизмы работают лучше, если система заранее знает все требуемые/используемые зависимости приложения.
Использование модулей
Интересно узнать, из каких модулей состоит установленная у вас версия JDK? Используйте ключ list-modules. Именно так мне открылось знание о наличии в моей JDK 95 модулей.
Чтобы система могла идентифицировать пакет как модуль, он должен содержать module declaration — файл module-info.
module BARModule {
}
Для файла описания модуля в язык введены новые специальные ключевые слова: exports, module, open, opens, provides, requires, uses, with, to, transitive. С целью поддержки обратной совместимости «ключевыми» они являются только в module declaration, и это замечательно, так как их использование в вашем коде не повлияет на успешность компиляции.
requires – указывает на зависимость от другого модуля (это то, что подразумевается под усиленной инкапсуляцией):
module FOOModule {
requires BARModule;
}
В англоязычных источниках глядя на эти строки сказали бы, что модуль FOOModule read BARModule, мне же привычнее говорить, что модуль FOOModule зависит от модуля BARModule.
Не стоит забывать, что модуль BARModule должен быть добавлен в зависимости.
Кроме того, описывая зависимости, можно указать еще одно ключевое слово — transitive, которое позволит модулям, использующим FOOModule, использовать и BARModule без необходимости явно объявлять эту зависимость в module declaration. В противном случае такой код просто не скомпилируется:
module FOOModule {
requires transitive BARModule;
}
exports – определяет пакет модуля, в котором классы с модификатором public будут доступны вне этого модуля (кроме самих классов будут также доступны их внутренние public и protected):
module BARModule {
exports BARModule.ModuleExport;
}
Кроме того доступно расширение синтаксиса:
module BARModule {
exports BARModule.ModuleExport to FOOModule, BAZModule;
}
Указав через запятую после слова to перечень модулей, вы, таким образом, ограничите модули, которые могут использовать экспортируемый модуль.
provides…with – определяет модуль как реализацию некоего сервиса. То есть модуль становится service provider. Часть provides определяет интерфейс или абстрактный класс, а with определяет класс, реализующий обещанную функциональность:
module BARModule {
exports BARModule.ModuleExport to FOOModule, BAZModule;
provides BARModule.ModuleExport.BARServiceInterface with
}
Директива uses определяет сервис, используемый модулем. Модуль в таком случае становится service consumer:
module FOOModule {
requires transitive BARModule;
uses BARModule.ModuleExport.BARServiceInterface;
}
До Java 9, используя рефлексию, можно было получить информацию обо всех компонентах пакета/класса, в том числе приватных, а также изменять модификаторы и пр.
Теперь же, когда сильная инкапсуляция стала одной из ключевых особенностей модулей, решить проблему её нарушения призваны ключевые слова open, opens и расширение to:
module BARModule {
exports BARModule.ModuleExport to FOOModule, BAZModule;
provides BARModule.ModuleExport.BARServiceInterface with BARModule.ModuleExport.PublicBARServiceImplementation;
}
Данный код сделает пакет и public классы в нем (и по аналогии exports его public и protected внутренние классы) доступными во время выполнения. Кроме того, все содержимое пакета будет доступным через рефлексию.
module BARModule {
exports BARModule.ModuleExport to FOOModule, BAZModule;
opens BARModule.ModuleOpens to BAZModule;
provides BARModule.ModuleExport.BARServiceInterface with BARModule.ModuleExport.PublicBARServiceImplementation;
}
Расширением to задаются модули (список через запятую), для которых opens будет работать.
Последний, самый радикальный, способ открыть рефлексию в модуле – объявить весь модуль open. Тогда все пакеты и классы этого модуля будут доступны для использования во время выполнения программы и для рефлексии:
open module FOOModule {
requires transitive BARModule;
uses BARModule.ModuleExport.BARServiceInterface;
}
Как разработчик корпоративных продуктов должен отметить, что модульная архитектура особенно полезна в применении к большим проектам, реализующим огромное количество различных взаимодействий с пользователем.
Она позволяет делать разрабатываемую систему более управляемой, расширяемой, поддерживаемой. Кроме того, благодаря усиленной инкапсуляции, достигаемой при использовании системы модулей, можно оградить код от «неправильного использования», выставив наружу только API. Чётко определив зависимости еще на этапе написания кода, вы сможете быть уверенными в том, что в процессе эксплуатации система никогда внезапно не упадёт по причине отсутствия нужного класса в classpath.
Модуль 5. Урок 1. Уровни доступа в Java.
Для перемещения по курсу нужно зарегистрироваться
1. Модуль 1. Урок 1. Введение в Java. ↳ теория
2. Модуль 1. Урок 2. Виды языков программирования и место языка Java среди них. ↳ теория / тесты
3. Модуль 1. Урок 3. Из чего состоит Java. ↳ теория / тесты
4. Модуль 1. Урок 4. Основы работы в терминале (ознакомительный). ↳ теория / тесты
5. Модуль 1. Урок 5. Настройка окружающей среды для разработки на языке Java. ↳ теория / тесты
6. Модуль 2. Урок 1. Введение в ООП. ↳ теория / тесты
7. Модуль 2. Урок 2. Типы данных в Java. ↳ теория / тесты
8. Модуль 2. Урок 3. Работа с экземплярами в Java. ↳ теория / тесты
9. Модуль 2. Урок 4. Пакеты в Java. ↳ теория / тесты
10. Модуль 3. Урок 1. Основы использования и создания методов в классах. ↳ теория / тесты
11.
Модуль 3. Урок 2. Аргументы и результаты работы методов. Рефакторинг.
↳
теория
/
тесты
12. Модуль 3. Урок 3. Уровни методов в Java. ↳ теория / тесты
13. Модуль 3. Урок 4. Наследование в Java. ↳ теория / тесты
14. Модуль 3. Урок 5. Аннотация @Override в Java. ↳ теория / тесты
15. Модуль 4. Урок 1. Условный оператор IF в Java. ↳ теория / тесты
16. Модуль 4. Урок 2. Массивы в Java. ↳ теория / тесты
17. Модуль 4. Урок 3. Циклы в Java. ↳ теория / тесты
18. Модуль 4. Урок 4. Оператор SWITCH в Java. ↳ теория / тесты
19. Модуль 5. Урок 1. Уровни доступа в Java. ↳ теория / тесты
20. Модуль 5. Урок 2. Конструкторы в Java. ↳ теория / тесты
21. Модуль 5. Урок 3. Неизменяемые объекты. ↳ теория / тесты
22. Модуль 5. Урок 4. Паттерн проектирования Builder. ↳ теория / тесты
23. Модуль 5. Урок 5. Перечисления в Java. ↳ теория / тесты
24. Модуль 6. Урок 1. Составные строки в Java. ↳ теория / тесты
25. Модуль 6. Урок 2. Манипуляции c символами. ↳ теория / тесты
26.
Модуль 6. Урок 3. Преобразование строк в числа и обратно.
↳
теория
/
тесты
27. Модуль 7. Урок 1. Интерфейсы в Java. ↳ теория / тесты
28. Модуль 7. Урок 2. Абстрактные классы. ↳ теория / тесты
29. Модуль 7. Урок 3. Интерфейс List в Java. ↳ теория / тесты
30. Модуль 8. Урок 1. Nested (static) классы в Java. ↳ теория / тесты
31. Модуль 8. Урок 2. Inner (non-static) классы в Java. ↳ теория / тесты
32. Модуль 8. Урок 3. Анонимные классы в Java. ↳ теория / тесты
33. Модуль 9. Урок 1. Исключения в Java. ↳ теория / тесты
34. Модуль 9. Урок 2. Иерархия исключений. ↳ теория / тесты
35. Модуль 10. Урок 1. Проект ХО. ↳ теория
36. Модуль 10. Урок 2. Проект ХО. ↳ теория
37. Модуль 10. Урок 3. Проект ХО. ↳ теория
38. Модуль 10. Урок 4. Проект ХО. ↳ теория
Порой обучение продвигается с трудом. Сложная теория, непонятные задания… Хочется бросить. Не сдавайтесь, все сложности можно преодолеть. Рассказываем, как
Не понятна формулировка, нашли опечатку?
Выделите текст, нажмите ctrl + enter и опишите проблему, затем отправьте нам.
В течение нескольких дней мы улучшим формулировку или исправим опечатку
Что-то не получается в уроке?
Загляните в раздел «Обсуждение»:
- Изучите вопросы, которые задавали по уроку другие студенты — возможно, ответ на ваш уже есть
- Если вопросы остались, задайте свой. Расскажите, что непонятно или сложно, дайте ссылку на ваше решение. Обратите внимание — команда поддержки не отвечает на вопросы по коду, но поможет разобраться с заданием или выводом тестов
- Мы отвечаем на сообщения в течение 2-3 дней. К «Обсуждениям» могут подключаться и другие студенты. Возможно, получится решить вопрос быстрее!
Подробнее о том, как задавать вопросы по уроку
Понимание модулей Java 9
Java 9 | Отрывок
Что это такое и как их использовать
Пол Дейтель
Пол Дейтель
В этой статье я познакомлю вас с системой платформенных модулей Java 9 (JPMS), самой важной новой технологией разработки программного обеспечения на Java с момента ее создания.
. Модульность — результат Project Jigsaw — помогает разработчикам на всех уровнях работать более продуктивно при создании, обслуживании и развитии программных систем, особенно больших систем.
Что такое модуль?
Модульность добавляет более высокий уровень агрегации над пакетами. Ключевым новым языковым элементом является модуль — группа повторно используемых пакетов с уникальным именем, а также ресурсов (таких как изображения и XML-файлы) и дескриптор модуля , определяющий
- имя модуля .
- зависимости модуля (то есть другие модули, от которых зависит этот модуль)
- пакеты, которые он явно делает доступными для других модулей (все остальные пакеты в модуле
- ).0015 неявно недоступен для других модулей)
- предлагаемых услуг
- услуг, которые он потребляет
- к каким еще модулям он позволяет отражение
История
Платформа Java SE существует с 1995 года.
В настоящее время около 10 миллионов разработчиков используют ее для создания всего: от небольших приложений до устройств с ограниченными ресурсами, таких как Интернет вещей (IoT) и других встроенных устройств. — к крупномасштабным критически важным для бизнеса и критически важным системам. Существует огромное количество устаревшего кода, но до сих пор платформа Java в основном представляла собой монолитное универсальное решение. За прошедшие годы были предприняты различные усилия, направленные на модульность Java, но ни одна из них не получила широкого распространения — и ни одна из них не могла быть использована для модульности платформы Java.
Модуляризация платформы Java SE была сложной задачей, и на это ушло много лет. JSR 277: Система модулей Java была первоначально предложена в 2005 году для Java 7. Позже этот JSR был заменен JSR 376: Система модулей платформы Java и предназначен для Java 8. Платформа Java SE теперь модульная в Java 9, но только после Java 9. был отложен до сентября 2017 года.
Цели
Каждый модуль должен явно указывать свои зависимости.
Согласно JSR 376, ключевыми целями модуляризации платформы Java SE являются
- Надежная конфигурация. Модульность предоставляет механизмы для явного объявления зависимостей между модулями таким образом, чтобы они распознавались как во время компиляции, так и во время выполнения. Система может просмотреть эти зависимости, чтобы определить подмножество всех модулей, необходимых для поддержки вашего приложения.
- Строгая инкапсуляция — пакеты в модуле доступны другим модулям только в том случае, если модуль явно экспортирует их. Даже в этом случае другой модуль не может использовать эти пакеты, если только в нем явно не указано, что ему требуются возможности другого модуля. Это повышает безопасность платформы, поскольку меньшее количество классов доступно для потенциальных злоумышленников. Возможно, вы обнаружите, что рассмотрение модульности помогает вам создавать более чистые и логичные проекты.
- Масштабируемая платформа Java. Ранее платформа Java представляла собой монолит, состоящий из огромного количества пакетов, что усложняло ее разработку, обслуживание и развитие. Это не могло быть легко подмножество. Платформа теперь состоит из 95 модулей (это число может измениться по мере развития Java). Вы можете создавать собственные среды выполнения, состоящие только из модулей, необходимых для ваших приложений или устройств, на которые вы ориентируетесь. Например, если устройство не поддерживает графический интерфейс, вы можете создать среду выполнения, не включающую модули графического интерфейса, что значительно уменьшит размер среды выполнения.
- Большая целостность платформы. До Java 9 можно было использовать многие классы на платформе, которые не предназначались для использования классами приложения. Благодаря строгой инкапсуляции эти внутренние API действительно инкапсулированы и скрыты от приложений, использующих платформу. Это может сделать проблематичным перенос устаревшего кода на модульную Java 9, если ваш код зависит от внутренних API.
- Повышенная производительность — JVM использует различные методы оптимизации для повышения производительности приложения. JSR 376 указывает, что эти методы более эффективны, когда заранее известно, что требуемые типы расположены только в определенных модулях.
Перечисление модулей JDK
JEP 200: Модульный JDK
JEP 201: Модульный исходный код
JEP 220: модульные изображения времени
JEP 220: EncaplAle Modes Most AptAl. JEP 261: Модульная система JEP 275: Модульная упаковка Java Application JEP 282: JLink: Java Linker JSR 376: Платформа Java.0016 JSR 379: JAVA SE 9 Таблица 1. Модульность JEP и JSR Java Важным аспектом Java 9 является разделение JDK на модули для поддержки различных конфигураций. (См. «JEP 200: Модульный JDK». Все JEP и JSR модульности Java показаны в Таблице 1 . перечисляет набор модулей JDK, который включает стандартные модули, реализующие спецификацию Java Language SE (имена, начинающиеся с Ключевым мотивом модульной системы является строгая инкапсуляция. Тело объявления модуля может быть пустым или содержать различные директивы модуля , в том числе Ключевые слова требуется. Директива модуля Существует также директива требует переходной — подразумеваемой удобочитаемости . Рассмотрим следующую директиву из объявления модуля В этом случае любой модуль, который читает В соответствии с JSR 379 стандартные модули Java SE должны обеспечивать подразумеваемую читаемость во всех случаях, подобных описанному здесь. Кроме того, хотя стандартный модуль Java SE может зависеть от нестандартных модулей, он не должен предоставлять им подразумеваемую читаемость. Это гарантирует переносимость кода, зависящего только от стандартных модулей Java SE, между реализациями Java SE. экспорт и экспорт… в. Ан 
) Использование команды java из папки bin JDK с параметром --list-modules , например: java --list-modules java ), модули JavaFX (имена, начинающиеся с javafx ), модули, специфичные для JDK (имена, начинающиеся с jdk ) и модули, специфичные для Oracle (имена, начинающиеся с oracle ). За каждым именем модуля следует строка версии: @9 указывает на то, что модуль принадлежит к Java 9. модуль делает доступными для других модулей и многое другое. Дескриптор модуля — это скомпилированная версия объявления модуля, определенного в файле с именем 9.0115 модуль-info.java . Каждое объявление модуля начинается с ключевого слова module , за которым следует уникальное имя модуля и тело модуля, заключенное в фигурные скобки, например:
модуль имя модуля {
} требует , экспортирует , экспортирует , предоставляет с0116, использует , а открывает (каждое из которых мы обсудим). Как вы увидите позже, компиляция объявления модуля создает дескриптор модуля, который хранится в файле с именем module-info.class в корневой папке модуля. Здесь мы кратко представляем каждую директиву модуля. После этого мы представим фактические объявления модулей. экспортирует , модуль , открывает , открывает , предоставляет , требует , использует , с , а также в и переходное , которые мы представим позже, являются ключевыми словами с ограниченным доступом.
Они являются ключевыми словами только в объявлениях модулей и могут использоваться как идентификаторы в любом другом месте вашего кода. требует указывает, что этот модуль зависит от другого модуля — эта связь называется зависимостью модуля . Каждый модуль должен явно указывать свои зависимости. Когда модуль А 9Для 0115 требуется модуль B, модуль A считается для чтения модуля B, а модуль B — это для чтения модулем A. Чтобы указать зависимость от другого модуля, используйте требует , например: требует имя модуля ; требует статической директивы , указывающей, что модуль требуется во время компиляции, но является необязательным во время выполнения. Это известно как необязательная зависимость и не будет обсуждаться в этом введении.
Чтобы указать зависимость от другого модуля и убедиться, что другие модули, читающие ваш модуль, также читают эту зависимость (известную как подразумеваемая читаемость ), используйте требует транзитивного , например: требует транзитивного имя_модуля ; java.desktop : требует транзитивного java.xml ; java.desktop , также неявно читает java.xml . Например, если метод из модуля java.desktop возвращает тип из модуля java.xml , код в модулях, которые читают java.desktop , становится зависимым от java.xml . Без требует транзитивной директивы в объявлении модуля java.desktop , такие зависимые модули не будут компилироваться, если они не явно читать java. .
xml экспорт 9Директива модуля 0116 указывает один из пакетов модуля, чьи общедоступные типы (и их вложенные общедоступные и защищенные типы ) должны быть доступны для кода во всех других модулях. Директива exports…to позволяет вам точно указать в списке, разделенном запятыми, код какого модуля или модулей может получить доступ к экспортируемому пакету — это известно как экспорт
используется. Директива модуля uses определяет службу, используемую этим модулем, что делает модуль потребителем службы.
А сервис — это объект класса, который реализует интерфейс или расширяет абстрактный класс , указанный в директиве uses .
обеспечивает…с. Директива модуля обеспечивает…с указывает, что модуль обеспечивает реализацию службы, что делает модуль поставщиком службы . предоставляет часть директивы, определяющую интерфейс или абстрактный класс, указанный в модуле , использует , а с частью директивы указывает имя класса поставщика услуг, который реализует интерфейс или расширяет абстрактный класс .
открывать, открывать и открывать… до. До Java 9 отражение можно было использовать для изучения всех типов в пакете и всех членов типа — даже его частных членов — независимо от того, хотели вы разрешить эту возможность или нет. Таким образом, ничего не было действительно инкапсулировано.
Ключевым мотивом модульной системы является сильная инкапсуляция. По умолчанию тип в модуле недоступен для других модулей, если только он не является общедоступным типом и , который вы экспортируете в свой пакет. Вы предоставляете только те пакеты, которые хотите предоставить. В Java 9 это также относится к отражению.
Разрешение доступа к пакету только во время выполнения. Директива модуля opens в форме
открывает пакет
указывает, что конкретный пакет общедоступных типов (и их вложенных общедоступных и защищенных типов ) доступны для кода в других модулях только во время выполнения. Кроме того, все типы в указанном пакете (и все члены типов) доступны через отражение.
Разрешение доступа к пакету только во время выполнения для определенных модулей. Директива модуля открывает…до в форме
открывает пакет для списка модулей, разделенных запятыми
указывает, что конкретный пакет общедоступных типов (и их вложенных общедоступных и защищенных типов ) доступен для кода в перечисленных модулях только во время выполнения.
Все типы в указанном пакете (и все члены типов) доступны через отражение в коде в указанных модулях.
Разрешение доступа только во время выполнения ко всем пакетам в модуле. Если все пакеты в данном модуле должны быть доступны во время выполнения и через отражение для всех других модулей, вы можете открыть весь модуль, например:
открыть модуль имя модуля {
// директивы модуля
}
Отражение по умолчанию
публичные типы (и их вложенные публичные и защищенные типы). Однако код в других модулях может получить доступ ко всем типам в открытом пакете и ко всем членам этих типов, включая закрытых членов через setAccessible , как и в более ранних версиях Java.
Дополнительные сведения о setAccessible и отражении см. в документации Oracle.
Пол Дейтель, генеральный директор и главный технический директор Deitel & Associates, выпускник Массачусетского технологического института с 35-летним опытом работы в области вычислительной техники.
Он чемпион по Java и программирует на Java более 22 лет. Он и его соавтор, доктор Харви М. Дейтель, являются самыми продаваемыми в мире авторами языков программирования. Пол проводил курсы по Java, Android, iOS, C#, C++, C и интернет-программированию для промышленных, правительственных и академических клиентов по всему миру.
ПРИМЕЧАНИЕ. Эта статья взята из Java Magazine , сентябрь/октябрь 2017 г.
Java: разница между модулем, библиотекой и пакетом | by Ashley Gelwix
Библиотеки содержат модули, полные пакетов, полных классов Java
От малого к большому
В порядке от малого к большому: Пакет -> Модуль -> Библиотека.
Пакет содержит множество классов (файлов .java) и в основном представляет собой папку в ваших проектах Java.
Модуль содержит много пакетов (папок с файлами .java). Модуль — это, по сути, библиотека для одной цели.
Библиотека содержит множество модулей (модуль обычно упаковывается в виде одного файла .
jar). Библиотека может содержать много модулей, но обычно все они связаны какой-то темой.
Пакет
Пакет — это пространство имен, которое организует набор связанных классов и интерфейсов. Концептуально вы можете думать о пакетах как о разных папках на вашем компьютере. Вы можете хранить HTML-страницы в одной папке, изображения — в другой, а сценарии или приложения — в третьей. Поскольку программное обеспечение, написанное на языке программирования Java, может состоять из сотен или тысяч отдельных классов имеет смысл упорядочивать вещи, помещая связанные классы и интерфейсы в пакеты. [4]
Модуль
Модуль представляет собой набор связанных пакетов Java и связанных ресурсов с файлом дескриптора, который содержит информацию о том, какие пакеты/ресурсы предоставляются этим модулем, какие пакеты используются текущим модулем и некоторую другую информацию. . [5] Модуль Java — это механизм упаковки, позволяющий упаковать приложение Java или API Java в виде отдельного модуля Java.
Модуль Java упакован как модульный файл JAR . Модуль Java может указать, какие из содержащихся в нем пакетов Java должны быть видны другим модулям Java, использующим этот модуль. Модуль Java также должен указывать, какие другие модули Java требуются для выполнения его работы.
Java-модули — это новая функция в Java 9 через Java Platform Module System (JPMS). Система модулей платформы Java также иногда упоминается как Java Jigsaw или Project Jigsaw в зависимости от того, где вы читаете. Jigsaw было внутренним названием проекта во время разработки. Позже Jigsaw сменила название на Java Platform Module System. [1]
Библиотека
Библиотека Java — это просто набор классов, которые уже были написаны кем-то другим. Вы загружаете эти классы и сообщаете о них своему компьютеру, а затем можете использовать эти классы в своем коде. Это позволяет вам расширить возможности Java и полагаться на код, протестированный другими людьми, вместо того, чтобы делать все самостоятельно.