JEP 161: Compact Profiles

AuthorsBob Vandette, Mark Reinhold
OwnerBob Vandette
Created2012/08/15 20:00
Updated2014/08/04 19:59
StatusClosed / Delivered
JSRs3 MR, 160 MR, 337
Discussionjdk8 dash dev at openjdk dot java dot net
DependsJEP 138: Autoconf-Based Build System


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.


  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.


It is not a goal of this proposal to define a module system.


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).


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.rmi                    java.lang.instrument
java.lang.annotation         java.rmi.activation
java.lang.invoke             java.rmi.dgc      
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                     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
java.nio.charset             javax.xml         
java.nio.charset.spi         javax.xml.datatype
java.nio.file                javax.xml.namespace
java.nio.file.attribute      javax.xml.parsers 
java.nio.file.spi                javax.xml.transform           javax.xml.transform.dom     javax.naming
java.text                    javax.xml.transform.sax
java.text.spi                javax.xml.transform.stax    javax.naming.event
java.time            javax.naming.ldap
java.time.chrono             javax.xml.validation        javax.naming.spi
java.time.format             javax.xml.xpath   
java.time.temporal           org.w3c.dom                      org.w3c.dom.bootstrap       javax.sql.rowset
java.util                    javax.sql.rowset.serial
java.util.concurrent              javax.sql.rowset.spi
java.util.concurrent.atomic  org.xml.sax       
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                                         org.ieft.jgss

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:

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

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.


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.


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.