42
Ключевое новшество технологии JPMS заключается в том, что она
вводит новый элемент в Java. В предыдущих версиях Java были только
семь элементов – классы, интерфейсы, перечисления, аннотации, ошибки,
исключения и пакеты, а начиная с Java SE 9, появляется новый
структурный элемент – модуль. В то время, как пакет является
контейнером классов, интерфейсов, перечислений, аннотаций, исключений
и ошибок, модуль является контейнером пакетов.
В силу того, что модуль стал новым элементом виртуальной машины
Java, среда выполнения обрела возможность строгого контроля доступа. В
Java 8 разработчик может указать, что методы класса не могут быть видны
другими классами, объявив их приватными. В Java 9 разработчик может
указать, что пакет не может быть виден другим модулями, например, пакет
может быть скрыт внутри модуля.
Возможность скрывать пакеты приносит разработчикам широкие
преимущества для проектирования приложения. Например, исчезает
необходимость называть пакеты специальными именами, типа "impl" или
"internal" и в документации к коду указывать, что использование
определенных пакетов запрещено.
В тоже время, создание модуля является относительно простой
задачей. Модуль это обычный .jar файл, который содержит в корне файл
module-info.class. Файл module-info.class создается из файла module-
info.java во время компиляции.
Как указывалось выше, Java 9 для совместимости поддерживает
работу как модульного, так и немодульного кода. В силу этого, в Java 9
для использования модулей был добавлен специальный атрибут – путь
модулей (англ. modulepath), чтобы указывать путь к модулям, в то время,
как для работы с немодульным кодом используется атрибут – путь
классов (англ. classpath). Если модульный .jar файл находится на пути
43
классов, то средой выполнения он не будет рассматриваться как модуль,
его module-info.class будет проигнорирован и все его пакеты будут
открытыми. Если же модульный .jar файл находится на пути модулей,
тогда среда выполнения считывает его module-info.class и управляет
доступом к пакетам модуля в соответствии с его установками [35].
Кратко рассмотрим преимущества, которые предоставляет JPMS.
Модулизация JRE и JDK. Благодаря внедрению технологии JPMS
библиотеки JRE и JDK были разделены на небольшие модули, которые
можно использовать выборочно, например, при запуске виртуальной
машины можно передать список подключаемых модулей. Такая
возможность позволяет запускать приложения Java на устройствах с
ограниченными мощностями.
Упрощается тестирование и поддерживаемость. Технология JPMS
позволяет значительно упростить тестирование и поддерживаемость
приложения, так как каждый модуль имеет четкую ответственность и на
уровне среды выполнения обеспечивается инкапсуляция данного модуля.
Повышается производительность. В силу того, что среда выполнения
стала модульной, можно устанавливать перечень модулей, которые
необходимо загружать для работы приложения. В результате, создаются
условия для более эффективной настройки приложения, что позволяет
улучшить производительность.
Закрывается доступ к внутреннему API. Использование технологии
JPMS позволяет полностью закрыть доступ к внутреннему коду как JRE и
JDK, так пользовательским Java приложениям. Благодаря этому,
повышается надежность приложений и качество кода, а также улучшается
переносимость проектов с одной версии Java на другую версию [36].
В заключение, дадим обзор инструмента сервисов, который
предоставляет JPMS.
44
Каждый модуль может предоставлять любое количество сервисов,
если выполняются следующие правила. Во-первых, каждый сервис должен
реализовывать определенный интерфейс. Интерфейс может быть
определен как в стандартном API, так и быть частью сторонней
библиотеки. Во-вторых, модуль, предоставляющий сервис, должен
объявить сервис в своем файле module-info.java, используя директиву
"provides имя_интерфейса with имя_класса".
Если модуль использует сервис, он также должен выполнять ряд
правил. Во-первых, модуль должен иметь доступ к интерфейсу, сервис
которого он будет использовать. Во-вторых, этот модуль должен объявить
использование сервиса в своем файле module-info.java посредством
директивы "uses имя_интерфейса". В-третьих, данный модуль должен
использовать ServiceLoader API для получения объекта сервиса [30].
Классический пример для работы с сервисами JPMS с
использованием трех модулей представлен на рисунке 8.
Рисунок 8. Пример работы с сервисами JPMS.
***
Технологию OSGi и технологию JPMS можно, бесспорно, назвать
самыми важными модульными технологиями для Java. В тоже время, так
Использует сервис
Предоставляет сервис
Модуль A (API)
exports me.pavel.api;
Модуль B (Impl)
requires: me.pavel.api;
provides me.pavel.api.Manager
with me.pavel.impl.MgrImpl;
Модуль C (Client)
requires: me.pavel.api;
uses me.pavel.api.Manager;
ServiceLoader
API
45
как цели создания данных технологий немного отличались, между ними
существуют не только сходства, но и различия.
Рассмотрим основные сходства технологий. Во-первых, обе
технологии осуществляют разрешение зависимостей модулей. Во-вторых,
обе технологии позволяют управлять доступом к пакетам модулей. В-
третьих, и OSGi и JPMS создают возможности для предоставления и
потребления сервисов на межмодульном уровне. В-четвертых, для работы
с модулем обе технологии требуют наличие в модуле служебной
информацией – OSGi использует файл MANIFEST.MF, а JPMS использует
файл module-info.class.
Отметим и важнейшие различия. Во-первых, технология OSGi
требует поверх среды выполнения работу платформы OSGi, а JPMS
встроена в среду выполнения. Во-вторых, OSGi не осуществляет
модулизацию стандартных библиотек Java, а работает только с модулями
приложения. JPMS, в свою очередь, поддерживает модули обоих типов. В-
третьих, технология OSGi поддерживает динамическое изменение модулей
работающего кода, что осуществляется посредством управления
жизненного цикла модуля. JPMS такую функциональность не
обеспечивает. В-четвертых, технология OSGi поддерживает версионность
пакетов, в то время, как JPMS такую поддержку не осуществляет.
В заключение можно сказать, что технология JPMS, начиная с Java 9,
значительно сократит использование технологии OSGi. Объясняется это
тем, что JPMS встроена в среду выполнения и охватывает всю Java
целиком, что делает невозможным ее деактивацию. Одновременное же
использование двух модульных систем является скорее исключением.
ГЛАВА 3. РЕАЛИЗАЦИЯ СРЕДЫ ДЛЯ МОДУЛЬНОГО ПО
НА ЯЗЫКЕ JAVA
46
3.1. Постановка задачи и принципы разработки
Как указывалось в предыдущей главе данной работы, технология
OSGi используется уже более 15 лет. За этот период был накоплен
громадный опыт использования OSGi и разработки модульных
приложений на Java. Кроме того, было разработано большое количество
программ и библиотек, которые упрощают использование OSGi и
добавляют значительный объем новой функциональности.
Одной из самых популярных программ для работы с OSGi является
Apache Karaf. Данная программа является средой выполнения для
модульного ПО на основе платформы OSGi и предоставляет следующие
возможности:
Горячее развертывание (англ. hot deployment). Для того, чтобы
развернуть файл его достаточно добавить в директорию. Программа
сама определит тип файла и постарается его развернуть.
Полноценная консоль. Apache Karaf обеспечивает полноценную Unix-
подобную консоль, посредством которой можно управлять средой.
Динамическая конфигурация. Программа предоставляет перечень
команд, которые позволяют менять конфигурацию работающей среды.
Развитая система логгирования. Apache Karaf поддерживает все
популярные платформы логгирования, такие, как SLF4J, LOG4J и т.д.
Работа с различными источниками. Apache Karaf позволяет работать с
такими источниками, как репозиторий Maven, веб-ресурсы (используя
протокол HTTP) и файловое пространство.
Удаленная работа. Программа включает в себя SSH сервер,
позволяющий использовать консоль удаленно.
Безопасность. Apache Karaf включает в себя полноценные платформы
безопасности (основанные на JAAS) и обеспечивает механизм
безопасности, основанный на ролях.
47
Поддержка различных OSGi платформ. Программа может работать с
различными реализациями OSGi платформы. Например, по
умолчанию Apache Karaf использует Apache Felix, но может работать
и с Equinox [26].
Проект Apache Karaf существует почти 10 лет и за это время стал
стандартной средой для работы с OSGi. Например, практические задания
во многих учебных материалах по работе с OSGi показываются с
использованием Apache Karaf. Кроме того, многие примеры программ,
работающих на OSGi, также приведены для работы с Apache Karaf.
Одна из причин популярности Apache Karaf заключается в том, что
стандартная среда поверх модульной системы крайне удобна, так как
большая часть нужной функциональности модульного приложения
заложено в среде выполнения. В результате, отпадает необходимость
дублирование данной функциональности для каждого модульного проекта,
что позволяет сократить время разработки, повышает поддерживаемость
программы и ее качество.
В тоже время, для технологии JPMS такой среды выполнения не
существует, что объясняется тем, что технология JPMS является очень
новой технологии. Широкие возможности, которые предоставляет такая
среда и отсутствие ее аналогов для технологии JPMS можно назвать
важнейшими причинами создания нового продукта.
Рассмотрим характеристики и требования к разрабатываемой среде
выполнения приложений (СВП).
СВП должна быть реализована на языке программирования Java и
должна обеспечить высокий уровень универсальности для выполнения
модульных приложений, разработанных на этом языке. Основная
функциональность среды заключается в том, чтобы осуществлять
выполнение модульного приложения – см. рисунок 9.
48
Рисунок 9. Схематичное представление использования СВП.
В силу того, что СВП должна работать поверх модульной системы
JPMS, каждое приложение должно представлять собой совокупность JPMS
модулей. Для каждого приложения СВП должна создавать отдельный
JPMS слой (англ. layer), что позволит разграничивать приложения и их
модули. Необходимо, чтобы на одном экземпляре СВП одновременно
могло работать неограниченное количество приложений - см. рисунок 9,
где показана одновременная работа двух приложений (А и B).
Каждое приложение должно иметь свой уникальный XML-
дескриптор, в котором будут указаны используемые данным приложением
модули. СВП должна считывать дескриптор нужного приложения и
осуществлять его запуск.
Помимо основной функциональности СВП также должна:
Поддерживать для каждого модуля приложения активатор,
аналогично активатору в технологии OSGi. Каждый активатор должен
Приложение A
Модуль
приложения
Среда выполнения Java SE 9
Модуль
Java SE 9
Модуль
Java SE 9
Модуль
Java SE 9
Среда выполнения приложений
Аппаратное обеспечение
Драйвер
Драйвер
Драйвер
Операционная система
Модуль
приложения
Приложение B
Модуль
приложения
Модуль
приложения
49
реализовывать интерфейс с двумя методами – один метод будет
вызываться, когда приложение стартует, другой метод будет
вызываться, когда приложение останавливается.
Поддерживать раздельное логгирование для приложений и самой
СВП, если логгирование осуществляется с помощью SLF4J.
Предоставлять список работающих приложений.
Предоставлять информацию обо всех JPMS сервисах в разрезе
приложения.
Предоставлять информацию обо всех текущих потоках (англ. thread)
JVM.
Предоставлять дамп (англ. dump) всех текущих потоков JVM.
СВП должна работать в двух режимах – без поддержки интерфейса
командной строки (англ. command line interface (CLI)) и с поддержкой CLI.
Если работа осуществляется без поддержки CLI, то установки для СВП
должны передаваться через параметры JVM, используя ключ –D.
Например, должна быть возможность передать список приложений,
которые необходимо запустить. Если работа осуществляется с поддержкой
CLI, то должны быть использованы два модульных приложений клиент и
сервер, которые расширяют функциональность СВП.
Приложения клиент и сервер должны подчиняться общим
требованиям СВП и иметь свои XML-дескрипторы. Данные приложения
должны:
Обеспечивать интерфейс командной строки для работы с СВП. В том
числе:
o Выводить информацию о существующих командах.
o Осуществлять выполнение скрипта с содержанием команд, что
позволит не повторять команды каждый раз, а сохранять их в
файл для повторного использования.
50
o Включать команды для управления соединением между клиентом
и сервером.
Работать по сетевому протоколу RMI с поддержкой защищенной
передачи данных.
Поддерживать работу в двух конфигурациях – когда клиент и сервер
работают в одной виртуальной машине (А) и когда клиент и сервер
работают на двух виртуальных машинах (B) - см. рисунок 10.
Конфигурация B будет, в основном, применяться тогда, когда клиент
и сервер работают на разных аппаратных устройствах, соединенных
сетью.
Поддерживать добавление новых команд в консоль с использованием
API. Необходимость данной функциональности объясняется тем, что
некоторые приложения могут предоставлять пользователю
возможность выполнения посредством консоли своих специальных
команд.
Рисунок 10. Две конфигурации приложения клиент и сервер.
Таким образом, СВП должна стать универсальной средой
выполнения для модульного ПО, которая позволит снизить стоимость и
время разработки модульного ПО и оптимизировать его сопровождение.
Разработка программного обеспечения это не только отдельное
направление в информационных технологиях, но и целая вселенная
Конфигурация A
Конфигурация B
Среда выполнения Java
Среда выполнения
приложений
Клиент
Сервер
Среда выполнения Java
Среда выполнения
приложений
Клиент
Среда выполнения Java
Среда выполнения
приложений
Сервер
51
стандартов, методик, методологий, техник, соглашений, спецификаций,
лучших практик, шаблонов, рекомендаций и т.п. Объединяя все
перечисленное термином принципы разработки, кратко отметим основные
принципы, которые должны быть использованы при разработке СВП.
Процесс разработки должен быть итеративным и состоять из двух
итераций. Каждая итерация должна включать в себя следующие действия:
планирование, проектирование, реализация, тестирование, оценка. На
первой итерации должна быть разработана СВП, а на второй итерации
приложения клиент и сервер.
Среди основных принципов проектирования следует выделить
следующие принципы:
1. Грамотное и эффективное использование принципов объектно-
ориентированного программирования: инкапсуляции, наследования и
полиморфизма. Инкапсуляции (англ. encapsulation) включает в себя:
а) объединение данных и кода, который осуществляется операции над
этими данными; б) максимальное сокрытие данных и кода от
внешнего вмешательства. Наследование (англ. inheritance) это
механизм, посредством которого тип приобретает некоторые или все
свойства другого типа. Наследование также поддерживает концепцию
иерархической классификации. Полиморфизм (англ. polymorphism)
означает различное поведение объектов в зависимости от их типа [48].
2. Слабое зацепление (англ. loose coupling), под которым понимается
создание такого взаимодействия между элементами системы, при
котором данные элементы зависят друг от друга в наименьшей
возможной степени [58].
3. Сильная связность (англ. high cohesion), под которой понимается такое
создание элементов системы, при котором каждый элемент обладал