JEP 161: Compact Profiles

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

1. Define the Profiles themselves.

2. Define some means to identify the current Profile at runtime.

3. Ensure that the result is testable, so that appropriate conformance and quality tests can be run against implementations of each Profile.

4. Enhance existing JDK tools to support the creation of applications that can run on specific Profiles.

5. 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                    java.rmi.activation         java.lang.management
java.lang.annotation         java.rmi.registry           java.security.acl
java.lang.invoke             java.rmi.server             java.util.prefs
java.lang.ref                java.sql                    javax.annotation.processing
java.lang.reflect            javax.rmi.ssl               javax.lang.model
java.math                    javax.sql                   javax.lang.model.element
java.net                     javax.transaction           javax.lang.model.type
java.nio                     javax.transaction.xa        javax.lang.model.util
java.nio.channels            javax.xml                   javax.management
java.nio.channels.spi        javax.xml.datatype          javax.management.loading
java.nio.charset             javax.xml.namespace         javax.management.modelbean
java.nio.charset.spi         javax.xml.parsers           javax.management.monitor
java.nio.file                javax.xml.stream            javax.management.openmbean
java.nio.file.attribute      javax.xml.stream.events     javax.management.relation
java.nio.file.spi            javax.xml.stream.util       javax.management.remote
java.security                javax.xml.transform         javax.management.remote.rmi
java.security.cert           javax.xml.transform.dom     javax.management.timer
java.security.interfaces     javax.xml.transform.sax     javax.naming
java.security.spec           javax.xml.transform.stax    javax.naming.directory
java.text                    javax.xml.transform.stream  javax.naming.event
java.text.spi                javax.xml.validation        javax.naming.ldap
java.util                    javax.xml.xpath             javax.naming.spi
java.util.concurrent         org.w3c.dom                 javax.script
java.util.concurrent.atomic  org.w3c.dom.bootstrap       javax.security.auth.kerberos
java.util.concurrent.locks   org.w3c.dom.events          javax.security.sasl
java.util.jar                org.w3c.dom.ls              javax.sql.rowset
java.util.logging            org.xml.sax                 javax.sql.rowset.serial
java.util.regex              org.xml.sax.ext             javax.sql.rowset.spi
java.util.spi                org.xml.sax.helpers         javax.tools
java.util.zip                                            javax.xml.crypto
javax.crypto                                             javax.xml.crypto.dom
javax.crypto.interfaces                                  javax.xml.crypto.dsig
javax.crypto.spec                                        javax.xml.crypto.dsig.dom
javax.net                                                javax.xml.crypto.dsig.keyinfo
javax.net.ssl                                            javax.xml.crypto.dsig.spec
javax.security.auth                                      org.ieft.jgss
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.

The JMX Remote API is proposed for compact3 to allow for remote management of small devices. This creates a challenge because the RMI connector is specified to support the IIOP transport (in addition to the RMI default transport) and so requires CORBA. It may therefore be necessary to change the JMX Remote API so that support for the IIOP protocol is downgraded to optional.

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.

• jar — The JAR-file manifest specification will be extended with a new attribute which can be used to specify the minimum Profile required by the code in a JAR file. A new command-line option will be added to the jar tool to make it convenient to create JAR files with that attribute in their manifests.

• java — The Java launcher will be enhanced to read and interpret the new minimum-Profile manifest attribute in JAR files. Whether it should be an error or a warning to run a JAR file on a Profile smaller than the minimum it specifies is an open issue.

• javadoc — The Platform API Specification will need to identify which API classes are in which Profiles. The javadoc tool will be enhanced to display this information.

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, jar, java, 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