JEP 161: Compact ProfilesJEP 161: Compact ProfilesAuthorsBob Vandette, Mark ReinholdOwnerBob VandetteTypeFeatureScopeSEStatusClosed / DeliveredRelease8JSRs3 MR, 160 MR, 337Discussionjdk8 dash dev at openjdk dot java dot netEffortMDurationMDependsJEP 138: Autoconf-Based Build SystemCreated2012/08/15 20:00Updated2023/01/26 23:37Issue8046151Summary
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.  The javadoc 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

InstallingContributingSponsoringDevelopers' GuideVulnerabilitiesJDK GA/EA BuildsMailing listsWiki
                      · IRCBylaws · CensusLegalWorkshopJEP ProcessSource codeMercurialGitHubToolsGitjtreg harnessGroups(overview)AdoptionBuildClient LibrariesCompatibility & Specification ReviewCompilerConformanceCore LibrariesGoverning BoardHotSpotIDE Tooling & SupportInternationalizationJMXMembersNetworkingPortersQualitySecurityServiceabilityVulnerabilityWebProjects(overview,
      archive)AmberBabylonCRaCCaciocavalloClosuresCode ToolsCoinCommon VM InterfaceCompiler GrammarDetroitDevelopers' GuideDevice I/ODukeGalahadGraalIcedTeaJDK 7JDK 8JDK 8 UpdatesJDK 9JDK
      (…,
       21,
       22,
       23)JDK UpdatesJavaDoc.NextJigsawKonaKullaLambdaLanaiLeydenLilliputLocale EnhancementLoomMemory Model UpdateMetropolisMission ControlMulti-Language VMNashornNew I/OOpenJFXPanamaPenrosePort: AArch32Port: AArch64Port: BSDPort: HaikuPort: Mac OS XPort: MIPSPort: MobilePort: PowerPC/AIXPort: RISC-VPort: s390xPortolaSCTPShenandoahSkaraSumatraTiered AttributionTsanType AnnotationsValhallaVeronaVisualVMWakefieldZeroZGC

        © 2024 Oracle Corporation and/or its affiliates
        Terms of Use
        ·
        
            License: GPLv2
        · Privacy
        · Trademarks
