Лабораторная работа № IX : Модульная система Java.

(проект лаб , будет правиться по результатам лаб 8)

Лабораторная работа № 9 — «Java Platform Module System»

Студент генерирует в ИИ проект:


finance-parent/
├── finance-core/
│   └── src/main/java/
│       ├── module-info.java
│       └── ru/fa/finance/...
│
└── finance-cli/
    └── src/main/java/
        ├── module-info.java
        └── ru/fa/finance/cli/...

finance-core:


module ru.fa.finance.core {
    exports ru.fa.finance.model;
    exports ru.fa.finance.service;
}

finance-cli:


module ru.fa.finance.cli {
    requires ru.fa.finance.core;
}

В finance-core также создаётся:


ru.fa.finance.internal

которая не экспортируется.

Студент сначала использует публичный API корректно, а затем намеренно пытается импортировать класс ru.fa.finance.internal.InternalCalculator из finance-cli и фиксирует ошибку.

Это демонстрирует разницу:


public внутри класса
        ≠
публично доступен всему приложению

public + package exported by module
        →
доступен другому модулю

JPMS позволяет модулю явно задавать имя, зависимости и экспортируемый API, а также усиливает инкапсуляцию относительно одних только пакетов.

Эксперимент exports vs opens. Механизм из ЛР №8 пытается рефлексивно получить закрытый член класса из другого модуля. Студент сравнивает:


exports ru.fa.finance.model;

с:


opens ru.fa.finance.model
    to ru.fa.finance.reflect;

и объясняет, почему это разные права.

Automatic modules. Студент получает обычный JAR без module-info.java, помещает его на module path и исследует:

bash
jar --describe-module --file legacy-utils.jar


Обычный JAR без module descriptor, оказавшийся на module path, может рассматриваться как automatic module.

Финальный эксперимент — jlink. Студент создаёт runtime image для приложения. jlink предназначен для сборки собственного runtime image из заданного набора модулей и их транзитивных зависимостей.

Результат сравнивается с обычным запуском:


system JDK + classpath/module-path
vs
custom runtime image


В отчёт включаются module-info.java, схема зависимостей модулей, размер полученного image и ответы на вопросы requires, exports, opens, automatic module, сильная инкапсуляция.


Вопросы для углубления: Зачем введена модульная система Java (JPMS)?Что
описывает module-info. java
(requires/exports/opens)?Что такое сильная
инкапсуляция модулей и чем она отличается от
пакетов?Какие проблемы возникают при миграции
«старых» проектов на модули?Что такое automatic
modules и когда они появляются?

Автор: к.п.н., Румянцев Сергей Александрович, доцент Финансового университета при Правительстве РФ; доцент ОЧУВО Международного инновационного университета; Консалтинг, управление разработкой ПО; системный и бизнес анализ; менеджмент; аналитиз данных; управление ИТ. Телефон для связи +79269444818 (мессенджеры)   Короткая ссылка:
(проект лаб , будет правиться по результатам лаб 8)

Лабораторная работа № 9 — «Java Platform Module System»

Студент генерирует в ИИ проект:


finance-parent/
├── finance-core/
│   └── src/main/java/
│       ├── module-info.java
│       └── ru/fa/finance/...
│
└── finance-cli/
    └── src/main/java/
        ├── module-info.java
        └── ru/fa/finance/cli/...

finance-core:


module ru.fa.finance.core {
    exports ru.fa.finance.model;
    exports ru.fa.finance.service;
}

finance-cli:


module ru.fa.finance.cli {
    requires ru.fa.finance.core;
}

В finance-core также создаётся:


ru.fa.finance.internal

которая не экспортируется.

Студент сначала использует публичный API корректно, а затем намеренно пытается импортировать класс ru.fa.finance.internal.InternalCalculator из finance-cli и фиксирует ошибку.

Это демонстрирует разницу:


public внутри класса
        ≠
публично доступен всему приложению

public + package exported by module
        →
доступен другому модулю

JPMS позволяет модулю явно задавать имя, зависимости и экспортируемый API, а также усиливает инкапсуляцию относительно одних только пакетов.

Эксперимент exports vs opens. Механизм из ЛР №8 пытается рефлексивно получить закрытый член класса из другого модуля. Студент сравнивает:


exports ru.fa.finance.model;

с:


opens ru.fa.finance.model
    to ru.fa.finance.reflect;

и объясняет, почему это разные права.

Automatic modules. Студент получает обычный JAR без module-info.java, помещает его на module path и исследует:

bash
jar --describe-module --file legacy-utils.jar


Обычный JAR без module descriptor, оказавшийся на module path, может рассматриваться как automatic module.

Финальный эксперимент — jlink. Студент создаёт runtime image для приложения. jlink предназначен для сборки собственного runtime image из заданного набора модулей и их транзитивных зависимостей.

Результат сравнивается с обычным запуском:


system JDK + classpath/module-path
vs
custom runtime image


В отчёт включаются module-info.java, схема зависимостей модулей, размер полученного image и ответы на вопросы requires, exports, opens, automatic module, сильная инкапсуляция.


Вопросы для углубления: Зачем введена модульная система Java (JPMS)?Что
описывает module-info. java
(requires/exports/opens)?Что такое сильная
инкапсуляция модулей и чем она отличается от
пакетов?Какие проблемы возникают при миграции
«старых» проектов на модули?Что такое automatic
modules и когда они появляются?

https://webprogr.ru/~hiWAQ
Короткая ссылка на новость:https://webprogr.ru/~hiWAQ


Последние новости

Лабораторная работа № IX : Модульная система Java.

(проект лаб , будет правиться по результатам лаб 8)

Лабораторная работа № 9 — «Java Platform Module System»

Студент генерирует в ИИ проект:


finance-parent/
├── finance-core/
│   └── src/main/java/
│       ├── module-info.java
│       └── ru/fa/finance/...
│
└── finance-cli/
    └── src/main/java/
        ├── module-info.java
        └── ru/fa/finance/cli/...

finance-core:


module ru.fa.finance.core {
    exports ru.fa.finance.model;
    exports ru.fa.finance.service;
}

finance-cli:


module ru.fa.finance.cli {
    requires ru.fa.finance.core;
}

В finance-core также создаётся:


ru.fa.finance.internal

которая не экспортируется.

Студент сначала использует публичный API корректно, а затем намеренно пытается импортировать класс ru.fa.finance.internal.InternalCalculator из finance-cli и фиксирует ошибку.

Это демонстрирует разницу:


public внутри класса
        ≠
публично доступен всему приложению

public + package exported by module
        →
доступен другому модулю

JPMS позволяет модулю явно задавать имя, зависимости и экспортируемый API, а также усиливает инкапсуляцию относительно одних только пакетов.

Эксперимент exports vs opens. Механизм из ЛР №8 пытается рефлексивно получить закрытый член класса из другого модуля. Студент сравнивает:


exports ru.fa.finance.model;

с:


opens ru.fa.finance.model
    to ru.fa.finance.reflect;

и объясняет, почему это разные права.

Automatic modules. Студент получает обычный JAR без module-info.java, помещает его на module path и исследует:

bash
jar --describe-module --file legacy-utils.jar


Обычный JAR без module descriptor, оказавшийся на module path, может рассматриваться как automatic module.

Финальный эксперимент — jlink. Студент создаёт runtime image для приложения. jlink предназначен для сборки собственного runtime image из заданного набора модулей и их транзитивных зависимостей.

Результат сравнивается с обычным запуском:


system JDK + classpath/module-path
vs
custom runtime image


В отчёт включаются module-info.java, схема зависимостей модулей, размер полученного image и ответы на вопросы requires, exports, opens, automatic module, сильная инкапсуляция.


Вопросы для углубления: Зачем введена модульная система Java (JPMS)?Что
описывает module-info. java
(requires/exports/opens)?Что такое сильная
инкапсуляция модулей и чем она отличается от
пакетов?Какие проблемы возникают при миграции
«старых» проектов на модули?Что такое automatic
modules и когда они появляются?

Рейтинг@Mail.ru