JEP 162: Prepare for Modularization

Подготовка к модуляризации

Ответственный	Alan Bateman
Тип	Feature
Область	SE
Статус	Closed / Delivered
Выпуск	8
JSRs	173 MR, 206 MR, 337
Обсуждение	jigsaw dash dev at openjdk dot java dot net
Трудоёмкость	M
Длительность	M
Блокирует	JEP 179: Document JDK API Support and Stability
Связан с	JEP 220: Modular Run-Time Images
Одобрен	Mark Reinhold
Создан	2012/08/31 20:00
Обновлён	2017/06/14 20:12
Задача	8046152

Аннотация

Внести изменения, которые облегчат будущий переход на модули в одном из следующих выпусков, предоставить новые инструменты, помогающие разработчикам подготовиться к модульной платформе, и объявить устаревшими некоторые API, которые серьёзно мешают модуляризации.

Что не является целью

Интеграция в JDK 8 кода модульной системы, разработанного в проекте Jigsaw, не является целью этой работы.

Описание

В связи с переносом проекта Jigsaw на более поздний выпуск этот JEP предлагает следующие изменения:

Устранить допущения о загрузке классов — в кодовой базе есть несколько мест, где сделаны допущения о загрузке классов. Многие такие проблемы уже выявлены и исправлены в проекте Jigsaw. В рамках подготовки к модулям предлагается провести более широкий аудит кодовой базы и, где возможно, внести исправления в JDK 8, чтобы этот код не пришлось менять снова при переходе на модули.
Использовать ServiceLoader — в JDK есть несколько API, у которых собственный механизм поставщиков услуг вместо java.util.ServiceLoader. Один из примеров — различные FactoryFinder в JAXP. Такие механизмы загрузки поставщиков создают проблемы для модулей, потому что они нестандартные. Мы предлагаем изменить эти API так, чтобы они использовали java.util.ServiceLoader. В некоторых случаях может потребоваться внести небольшие изменения в соответствующие спецификации.
Добавить в JDK инструмент командной строки, с помощью которого разработчики смогут разобраться в статических зависимостях своих приложений и библиотек — в рамках проекта Jigsaw был разработан полезный анализатор классов, с которым выявлять зависимости очень просто. Этот анализатор классов будет доработан, чтобы упростить выявление использования нестандартных и внутренних API JDK. Он станет полезным дополнением к предупреждениям, которые выдаёт javac при компиляции кода, использующего внутренние API JDK.
Объявить устаревшими API Java SE, которые будут серьёзно мешать модуляризации — эти API будут объявлены устаревшими с расчётом на их полное удаление при появлении модульной системы. Сейчас мы планируем объявить устаревшими следующие методы:
```
java.util.logging.LogManager.addPropertyChangeListener
java.util.logging.LogManager.removePropertyChangeListener
java.util.jar.Pack200.Packer.addPropertyChangeListener
java.util.jar.Pack200.Packer.removePropertyChangeListener
java.util.jar.Pack200.Unpacker.addPropertyChangeListener
java.util.jar.Pack200.Unpacker.removePropertyChangeListener
```
Объявить устаревшими специфичные для JDK API, которые серьёзно мешают модуляризации. На данный момент самая проблемная область — JAAS, где мы планируем объявить устаревшим пример обработчика обратного вызова com.sun.security.auth.callback.DialogCallbackHandler. Мы также можем рассмотреть добавление метода implies в java.security.Principal, поскольку это устранило бы необходимость в com.sun.security.auth.PrincipalComparator.
Пересмотреть нормативные ссылки спецификаций на файлы в $JAVA_HOME и, где возможно, понизить статус этих ссылок до ненормативного. Если понизить статус этих ссылок, в одном из будущих выпусков можно будет изменить расположение (или формат) этих файлов. Например, файл свойств для валют можно будет перенести в место, закрытое внутри модуля.

Тестирование

Изменение существующих API для использования java.util.ServiceLoader, скорее всего, потребует разработки новых тестов.

Новые инструменты командной строки или параметры времени выполнения потребуют новых тестов.

Если будет определён стандартный API PrincipalComparator, для него потребуются новые тесты на соответствие и модульные тесты.

Риски и допущения

Существует небольшой риск, что изменение реализации, например для устранения допущений, связанных с загрузкой классов, может вызвать побочные эффекты. Как и в случае со всеми ошибками и возможностями, мы предполагаем, что обширное тестирование JDK 8 позволит выявить такие проблемы.

Влияние

JCK: изменения спецификации, скорее всего, потребуют обновления тестов на соответствие для соответствующих областей.
Совместимость: чтобы объявить методы или возможности устаревшими или запланировать их удаление, потребуется время на тщательный анализ последствий.