openjdk.ruOpenJDK на русском

JEP 161: Compact Profiles

Компактные профили

AuthorsBob Vandette, Mark Reinhold
ОтветственныйBob Vandette
ТипFeature
ОбластьSE
СтатусClosed / Delivered
Выпуск8
JSRs3 MR, 160 MR, 337
Обсуждениеjdk8 dash dev at openjdk dot java dot net
ТрудоёмкостьM
ДлительностьM
Зависит отJEP 138: Autoconf-Based Build System
Создан2012/08/15 20:00
Обновлён2026/07/29 19:00
Задача8046151

Аннотация

Определить несколько профилей — подмножеств спецификации платформы Java SE, чтобы приложения, которым не нужна вся платформа, можно было развёртывать и запускать на небольших устройствах.

Цели

  1. Определить сами профили.

  2. Определить способ узнать текущий профиль во время выполнения.

  3. Обеспечить тестируемость результата, чтобы на реализациях каждого профиля можно было запускать соответствующие тесты на соответствие и качество.

  4. Доработать существующие инструменты JDK так, чтобы они поддерживали создание приложений, которые могут работать на конкретных профилях.

  5. По возможности учесть будущий переход к более гибкому подходу на основе системы модулей.

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

Определение системы модулей не является целью этого предложения.

Мотивация

Основная цель этой возможности — дать приложениям, которым не нужна вся платформа Java SE, работать на устройствах с ограниченными ресурсами. Приложение, которое не использует графический стек Swing/AWT/2D, например, или использует вместо него Java FX, может заметно сэкономить место, если будет работать на профиле, не включающем эти API.

В более широком смысле эта возможность должна позволить перенести приложения, которые сейчас построены на Java ME Connected Device Configuration (CDC), на соответствующие профили платформы Java SE. Это часть долгосрочной работы по сближению CDC с Java SE.

Дополнительное преимущество: эта возможность, вероятно, позволит быстрее загружать приложения, которые поставляются с собственной средой Java Runtime Environment (JRE).

Описание

Сейчас мы предполагаем определить три профиля, выстроенных в виде дополняющих друг друга уровней, так что каждый профиль содержит все API профилей меньшего размера. Каждый профиль будет задавать определённый набор пакетов Java API; соответствующая JRE будет включать, насколько это осуществимо, только классы, нативный код и другие ресурсы, необходимые для поддержки этих API.

Ниже приведён первоначальный черновой вариант наборов пакетов API для каждого профиля. Пока мы называем профили compact1, compact2 и compact3.

compact1                     compact2                    compact3
--------------------------   -----------------------     --------------------------
java.io                      java.rmi                    java.lang.instrument
java.lang.annotation         java.rmi.activation         java.lang.management
java.lang.invoke             java.rmi.dgc                java.security.acl
java.lang.ref                java.rmi.registry           java.util.prefs
java.lang.reflect            java.rmi.server             javax.annotation.processing
java.math                    java.sql                    javax.lang.model
java.net                     javax.rmi.ssl               javax.lang.model.element
java.nio                     javax.sql                   javax.lang.model.type
java.nio.channels            javax.transaction           javax.lang.model.util
java.nio.channels.spi        javax.transaction.xa        javax.management
java.nio.charset             javax.xml                   javax.management.loading
java.nio.charset.spi         javax.xml.datatype          javax.management.modelmbean
java.nio.file                javax.xml.namespace         javax.management.monitor
java.nio.file.attribute      javax.xml.parsers           javax.management.openmbean
java.nio.file.spi            javax.xml.stream            javax.management.relation
java.security                javax.xml.stream.events     javax.management.remote
java.security.cert           javax.xml.stream.util       javax.management.remote.rmi
java.security.interfaces     javax.xml.transform         javax.management.timer
java.security.spec           javax.xml.transform.dom     javax.naming
java.text                    javax.xml.transform.sax     javax.naming.directory
java.text.spi                javax.xml.transform.stax    javax.naming.event
java.time                    javax.xml.transform.stream  javax.naming.ldap
java.time.chrono             javax.xml.validation        javax.naming.spi
java.time.format             javax.xml.xpath             javax.security.auth.kerberos
java.time.temporal           org.w3c.dom                 javax.security.sasl
java.time.zone               org.w3c.dom.bootstrap       javax.sql.rowset
java.util                    org.w3c.dom.events          javax.sql.rowset.serial
java.util.concurrent         org.w3c.dom.ls              javax.sql.rowset.spi
java.util.concurrent.atomic  org.xml.sax                 javax.tools
java.util.concurrent.locks   org.xml.sax.ext             javax.xml.crypto
java.util.function           org.xml.sax.helpers         javax.xml.crypto.dom
java.util.jar                                            javax.xml.crypto.dsig
java.util.logging                                        javax.xml.crypto.dsig.dom
java.util.regex                                          javax.xml.crypto.dsig.keyinfo
java.util.spi                                            javax.xml.crypto.dsig.spec
java.util.stream                                         org.ieft.jgss
java.util.zip
javax.crypto
javax.crypto.interfaces
javax.crypto.spec
javax.net
javax.net.ssl
javax.script
javax.security.auth
javax.security.auth.callback
javax.security.auth.login
javax.security.auth.spi
javax.security.auth.x500
javax.security.cert

В отдельных редких случаях может потребоваться урезать классы, удалив из них методы, например, методы addPropertyChangeListener и removePropertyChangeListener, определённые в java.util.logging.LogManager, чтобы не разделять пакеты и не ссылаться на несуществующие типы.

JMX и JMX Remote API предлагается включить в compact3. Может потребоваться обновить JMX API, чтобы он не ссылался на типы из java.beans, которых нет. Что касается JMX Remote API, может потребоваться ограничить поддержку протокола RMI-IIOP, чтобы не включать CORBA.

Все существующие пакеты, не вошедшие ни в один из этих профилей, будут доступны только в полной JRE.

Необязательные компоненты

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

  • Провайдеры безопасности — профиль compact1 будет содержать минимальный набор провайдеров безопасности. Минимальный набор провайдеров будет выбран исходя из самых популярных и часто используемых алгоритмов. Все провайдеры, не вошедшие в compact1, будут определены как необязательные, и включать их в какой-либо дистрибутив не потребуется.

  • Ресурсы локализации для отдельных стран — все ресурсы локализации, кроме американских, будут определены как необязательные. Все необязательные ресурсы локализации будут упакованы и сгруппированы так, чтобы разработчик мог легко добавить их в любую JRE.

Определение профиля, который реализует работающая JRE

Опция java -version будет доработана так, чтобы сообщать профиль, который реализует данная JRE.

Файл release, расположенный в корневом каталоге образа, также будет обновлён: в него добавится свойство, указывающее реализованный профиль.

Сейчас мы не видим необходимости добавлять API или свойство Java, через которое выполняемый код мог бы узнать реализованный профиль.

Доработка инструментов и команд

  • javac — будет определена новая опция командной строки для указания целевого профиля. Если компилируемый исходный код ссылается на API вне этого профиля, это будет ошибкой компиляции.

  • javadoc — в спецификации API платформы нужно будет указать, какие классы API входят в какие профили. Инструмент javadoc будет доработан, чтобы показывать эту информацию.

  • jdeps — в этот инструмент будет добавлена опция командной строки, показывающая минимальный профиль, в который входит пакет или класс.

Изменения системы сборки

Система сборки JDK сейчас может создавать полную среду Java Runtime Environment (JRE) или полный Java Development Kit (JDK), то есть полную JRE вместе с набором инструментов разработки. Мы планируем доработать новую систему сборки, описанную в JEP 138, чтобы она при необходимости создавала три дополнительных компактных целевых образа JRE.

Альтернативы

Инструменты, которые статически анализируют class-файлы и удаляют неиспользуемые элементы, давно применяются для уменьшения размера Java-приложений. Однако применять такие инструменты к классам самой платформы проблематично, потому что любое существенное уменьшение размера требует конкретных знаний о приложениях, которые будут запускаться.

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

Java SE TCK необходимо изменить так, чтобы им можно было тестировать реализации любого заданного профиля. Тестовому агенту TCK не должны требоваться никакие API вне профиля compact1.

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

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

Определение профилей в Java SE 8 может усложнить перенос приложений на полностью модульную платформу Java SE, которая ожидается в одном из будущих выпусков. Профили, определённые в рамках этой работы, должны, насколько это возможно, согласовываться с текущей работой в Project Jigsaw.

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

Влияние

  • Другие компоненты JDK: javac, javadoc, как описано выше
  • Совместимость: ограниченное: для некоторых API нужны небольшие изменения спецификации
  • Опыт пользователя: ограниченное: доработка инструментов
  • TCK: значительное: TCK нужно разделить для поддержки профилей