-
JEP
-
Resolution: Delivered
-
P4
-
None
-
None
-
Bob Vandette, Mark Reinhold
-
Feature
-
Open
-
SE
-
3 MR, 160 MR, 337
-
-
M
-
M
-
161
Summary
Define a few subset Profiles of the Java SE Platform Specification so that applications that do not require the entire Platform can be deployed and run on small devices.
Goals
Define the Profiles themselves.
Define some means to identify the current Profile at runtime.
Ensure that the result is testable, so that appropriate conformance and quality tests can be run against implementations of each Profile.
Enhance existing JDK tools to support the creation of applications that can run on specific Profiles.
Take into account, to the extent possible, a future transition to a more flexible approach based upon a module system.
Non-Goals
It is not a goal of this proposal to define a module system.
Motivation
The primary motivation for this feature is to allow applications that do not require the entire Java SE Platform to run on resource-constrained devices. An application that does not use the Swing/AWT/2D graphics stack, e.g., or which uses Java FX instead, can achieve considerable space savings by running on top of a Profile that does not include those APIs.
More broadly, this feature is intended to enable the migration of applications currently built on top of the Java ME Connected Device Configuration (CDC) to appropriate Profiles of the Java SE Platform, part of the long-term effort to converge CDC with Java SE.
As a secondary benefit, this feature is likely to enable faster download times for applications that bundle their own Java Runtime Environment (JRE).
Description
We currently envision defining three Profiles, arranged in additive layers so that each Profile contains all of the APIs in Profiles smaller than itself. Each Profile will specify a specific set of Java API packages; the corresponding JRE will include, to the extent feasible, only the classes, native code, and other resources required to support those APIs.
Here is an initial draft of the sets of API packages in each Profile. For the moment we name the Profiles compact1, compact2, and 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
In a few rare cases it may be necessary to subset classes by removing methods, e.g., the addPropertyChangeListener and removePropertyChangeListener methods defined by java.util.logging.LogManager, to avoid spliting packages or referencing types that do not exist.
JMX and the JMX Remote API are proposed for compact3. It may be necessary to update the JMX API to avoid referencing types in java.beans that do not exist. In the case of the JMX Remote API then it may be necessary to downgrade support for the RMI-IIOP protocol to avoiding needing to include CORBA.
Any existing package not contained in one of these Profiles will be available only in the full JRE.
Optional components
In order to keep the size of the Profiles to a minimum, some non-API functionality will be defined as optional. This includes, but is not limited to:
Security Providers --- The compact1 Profile will contain a minimal set of security providers. The minimal set of providers will be selected based on the most popular and frequently-used algorithms. All providers not included in compact1 will be defined as optional and will not be required to be included in any distribution.
Country-specific localization resources --- All non-US localization resources will be defined as optional. All optional localization resources will be packaged and grouped in such a form as to be easily added to any JRE by a developer.
Identifying the Profile implemented by a running JRE
The java -version
option will be enhanced to report the Profile
implemented by the JRE in question.
The release
file, located in the top-level directory of the image,
will also be updated to include a property to indicate the implemented
Profile.
At this time we do not envision the need to add an API or Java Property for running code to indicate the implemented Profile.
Enhancements to tools and commands
javac
--- A new command-line option will be defined to specify the intended target Profile. It will be a compile-time error for source code being compiled to reference APIs outside of that Profile.javadoc
--- The Platform API Specification will need to identify which API classes are in which Profiles. Thejavadoc
tool will be enhanced to display this information.jdeps
--- This tool will be updated with a command-line option to show the minimum profile that a package or class is contained in.
Build-system modifications
The JDK build system can currently produce a full Java Runtime
Environment (JRE) or a complete Java Development Kit (JDK), which is the
full JRE plus a set of development tools. We plan to enhance the new
build system described in
JEP 138
to optionally produce the three
additional Compact target JRE images.
Alternatives
Tools which statically analyze class files and remove unused elements have long been used to reduce the size of Java applications. Applying such tools to classes in the Platform itself, however, is problematic because any significant reduction in size requires specific knowledge of the applications to be run.
Testing
The Java SE TCK must be modified so that it can test implementations of any specified Profile. The TCK's test agent must not require the use of any APIs outside of the compact1 Profile.
All regression and functional tests must be examined to determine the impact that the introduction of Profiles will have upon them.
Risks and Assumptions
The definition of Profiles in Java SE 8 may complicate the migration of applications to the fully-modular Java SE Platform expected in a future release. The Profiles defined by this effort should, to the extent possible, be aligned with the ongoing work in Project Jigsaw.
There will likely be some minor impact upon existing APIs, to address situations in which existing API packages do not cleanly fall into one Profile or another.
Impact
- Other JDK components:
javac
,javadoc
, as described above - Compatibility: Limited: Minor spec changes required for some APIs
- User experience: Limited: Tool enhancements
- TCK: Significant: TCK must be split up to support Profiles
- is blocked by
-
JDK-8046128 JEP 138: Autoconf-Based Build System
- Closed
- relates to
-
JDK-8004265 Add build support for Compact Profiles
- Resolved
-
JDK-8004182 Add support for profiles in javac
- Closed
-
JDK-8006124 javadoc/doclet should be updated to support profiles
- Closed
-
JDK-8001048 JSR-160: Allow IIOP transport to be optional
- Resolved
-
JDK-8003256 (profiles) Add support for profile identification
- Resolved
-
JDK-8006524 JSR-3: Allows java.beans to be optional
- Resolved
-
JDK-8245247 Remove -profile option from javac
- Open
-
JDK-8245246 Deprecate -profile option in javac
- Resolved