Java SE is a very impressive platform indeed, but with all that functionality comes a large and ever increasing footprint. It stands to reason then that one of the more frequent requests from the community has been the desire to deploy only those components required for a particular application instead of the entire Java SE runtime environment. Referred to as subsetting, the benefits of such a concept would seem to be many:
- A smaller Java environment would require less compute resources, thus opening up a new domain of devices previously thought to be too humble for Java.
- A smaller runtime environment could be better optimized for performance and start up time.
- Elimination of unused code is always a good idea from a security perspective.
- If the environment could be pared down significantly, there may be tremendous benefit to bundling runtimes with each individual Java application.
- These bundled applications could be downloaded more quickly.
Despite these perceived advantages, the platform stewards (Sun, then Oracle) have been steadfast in their resistance to subsetting. The rationale for such a stance is quite simple: there was sincere concern that the Java SE platform would fragment. Agree or disagree, the Java SE standard has remained remarkably in tact over time. If you need any further evidence of this assertion, compare the state of Java SE to that of Java ME, particularly in the mobile telephony arena. Better still, look how quickly Android has spawned countless variants in its brief lifespan.
Nonetheless, a formal effort has been underway having the stated goal of providing a much more modular Java platform. Called Project Jigsaw, when complete, Java SE will be composed of a set of finer-grained modules and will include tools to enable developers to identify and isolate only those modules needed for their application. However, implementing this massive internal change and yet maintaining compatibility has proven to be a considerable challenge. Consequently full implementation of the modular Java platform has been delayed until Java 9.
Understanding that Java 9 is quite a ways off, an interim solution will be available for Java 8, called Compact Profiles. Rather than specifying a complete module system, Java 8 will define subset profiles of the Java SE platform specification that developers can use to deploy. At the current time three compact profiles have been defined, and have been assigned the creative names compact1, compact2, and compact3. The table that follows lists the packages that comprise each of the profiles. Each successive profile is a superset of its predecessor. That is to say, the compact2 profile contains all of the packages in compact1 plus those listed under the compact2 column below. Likewise, compact3 contains all of compact2 packages plus the ones listed in the compact3 column.
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
You may ask what savings can be realized by using compact profiles? As Java 8 is in pre-release stage, numbers will change over time, but let's take a look at a snapshot early access build of Java SE-Embedded 8 for ARMv5/Linux. A reasonably configured compact1 profile comes in at less than 14MB. Compact2 is about 18MB and compact3 is in the neighborhood of 21MB. For reference, the latest Java 7u21 SE Embedded ARMv5/Linux environment requires 45MB.
So at less than one-third the original size of the already space-optimized Java SE-Embedded release, you have a very capable runtime environment. If you need the additional functionality provided by the compact2 and compact3 profiles or even the full VM, you have the option of deploying your application with them instead.
In the next installment, we'll look at Compact Profiles in a bit more detail.