Ответ
Основные изменения касаются Java Platform Module System (JPMS), представленной в Java 9, и её последующего развития. Между 11 и 18 LTS-версиями были введены важные улучшения для удобства использования:
- JEP 403: Strongly Encapsulate JDK Internals (Java 16, закреплено в 17) — Внутренние API JDK (например,
sun.misc.Unsafe) по умолчанию стали строго инкапсулированы. Это повышает безопасность и стабильность. Для доступа требуется явное разрешение через--add-opens. - JEP 396: Strongly Encapsulate JDK Internals by Default (Java 16) — Предварительный шаг к JEP 403, установивший строгую инкапсуляцию по умолчанию.
- Упрощение миграции. Появились флаги для облегчения перехода с классического classpath на modulepath, помогающие обрабатывать автоматические модули и доступ к внутренним API.
- Улучшения в
jlinkиjpackage(Java 14+). Инструменты для создания собственных образов среды выполнения (JRE) и нативных пакетов приложений стали стабильнее и функциональнее, что напрямую связано с модульностью.
Почему это важно? Эти изменения окончательно закрепили модульность как основу платформы, повысили безопасность и упростили создание минимальных деплоябельных образов Java-приложений.
Ответ 18+ 🔞
Да что ж такое, блядь! Опять эти ваши модули, сука! Ну сидел себе народ на восьмёрке, как сыр в масле катался — classpath, jar'ники, всё по-пацански. А тут как началось с девятки... ёпта, ёперный театр!
Короче, слушай сюда, главная движуха — это Java Platform Module System (JPMS), которую в девятку впихнули, а дальше её только дожимали и дожимали, как последнюю сигарету в пачке. Между 11-й и 18-й LTS-версиями накрутили такого, что мама не горюй.
Вот тебе разбор полётов, чтобы не обосраться на ровном месте:
- JEP 403: Strongly Encapsulate JDK Internals (Java 16, закреплено в 17) — Это, сука, приговор! Раньше можно было через заднюю дверь лазить, типа
sun.misc.Unsafe— ну там, чёрная магия, оптимизации, всё дела. А теперь эти внутренние API JDK наглухо запаковали, как консервы. Безопасность, стабильность, бла-бла-бла. Хочешь лезть? Изволь флаг--add-opensпрописать, как мантру. Удивление пиздец у тех, кто на этом похалявил строил. - JEP 396: Strongly Encapsulate JDK Internals by Default (Java 16) — Это была, блядь, разведка боем перед JEP 403. Типа "ребята, привыкайте, скоро будет больно". Так и вышло.
- Упрощение миграции. Ну, понимаешь, народ-то орал, что модули — это пиздец и конец света. Вот и накидали флажков разных, чтобы переход с уютного classpath на суровый modulepath был не таким болезненным. Автоматические модули подлатали, доступ к внутренностям чуть приоткрыли — в общем, сделали вид, что заботятся.
- Улучшения в
jlinkиjpackage(Java 14+). Вот это, кстати, охуенно! Раньше тащить с собой целый JRE — это же овердохуища места. А теперь эти инструменты стали взрослыми. Собрал себе образ среды выполнения только с нужными модулями — и получил приложение, которое весит не как паровоз.jpackageвообще красава — завернёт всё в нативный пакет (deb, rpm, msi), чтобы пользователь даже не знал, на какой джаве это бегает.
А нахуя это всё, спрашивается? Да затем, блядь, что модульность — это теперь не эксперимент, а фундамент. Всё закрутили на безопасность, чтобы левые библиотеки не шарились по кишкам JDK. И главное — можно делать эти ваши "минимальные образы", которые и разворачивать легко, и места жрут как кот наплакал. Так что, хочешь не хочешь, а в эту хитрую жопу под названием JPMS придётся вникать, иначе останешься на обочине, как последний пидарас шерстяной.