Released in March 2014, the new version of Java was the event of the beginning of the year in the world computer. The articles and blog topics have abounded highlighting the revolution of Lambdas expressions or the relief of finally benefiting from a time management API worthy of the name. In contrast, the introduction of profiles within Java 8 has remained a subject rather confidential while it constitutes a big step for the future of the platform. Attempt to explain.
A little theory
Over time, the Java platform has grown in maturity but also in functionalities becoming the reference solution for developments in many fields. Adding features will ultimately lead to ever increasing size of the environment Java runtime better known as JRE (Java Runtime Environment). With Java 7, the full JRE revolved around 140 MB! This size is all the more problematic for many people of applications a lot of the features of the JRE are only not used (JMX or Corba for example).
Reducing the memory footprint of the Java platform has become a top priority for Oracle's Java teams. Without take into account the native code loaded by dynamic libraries, the JRE consists of a monolithic block of nearly 60 MB with the libraryrt.jar. Cut out this imposing block in sub-blocks is a necessity to modularize the JRE.
This modularization must notably lead to the following gains:
- Reduced startup time for the JVM;
- Reduced memory consumption;
- Clean the core of the platform by removing packages from the APIs with nothing to do and unused classesa Increased security due to the reduction of the core of the platform and therefore the potential attack surface;
- A Greater convergence between Java ME (embedded version) and Java SE.
This modularization project is not new and the Java developers have all heard of the Jigsaw project. Project how ambitious, Jigsaw was aiming for a complete modularization of the platform while also taking into account the following needs: - Addiction management based on good practices and errors of solutions like Maven, Apache Ivy or OSGI in particular;
- Isolation of dependencies to solve the versioning problem libraries;
- Allow application packaging in the form of modules rather that in the form of JAR
This approach required huge changes in depth within of the Java platform. In particular, it involves setting up a class loader also modular which induces great complexity for ensure backward compatibility.
Given the scale of the task and to finally deliver version 8 of Java, Oracle has decided to postpone this huge modularization project in Java 9 expected for 2016. Nevertheless, the initial work will not have been in vain since Java 8 decides to take a first step in this project modularisation by proposing the Compact profiles. If, at first glance, the mountain has given birth to a mouse, the reality is still much more pink. Indeed, the Compact profiles of Java 8 appropriate a part.
Basically, the expected benefits of the Jigsaw project:
- a Full compatibility with the JVM and Java language specifications;
- a substantial reduction in the memory footprint of the platform;
- a Removal of features that are not always useful anymore (CORBA by example);
- a operation for most applications and especially server applications.
Concretely, the Compact profiles of Java 8 are based on the packages.
Thus, a profile must contain complete packages. There is therefore no support for partial packages. In addition, a profile must be a closed set which implies that references to classes not present within the profile are prohibited. In fact, if a profile contains classes of another profile smaller it must contain them entirely which thus induces that the profiles are additive.
The profiles are 3 in number to which must be added the complete JRE.
Note that the compact1 profile is the smallest with a slightly smaller size below 10 MB, which is a space saving quite drastic. It corresponds to the heart of the Java platform and contains in particular the java.io, java.lang, java.nio, java.math, java.text, java.util, packages java.security, javax.security and java.text. The compact2 profile corresponds to compact1 to which invocation-related packages are added RMI, SQL and XML. Finally, the compact3 includes all the compact2 to which JMX-related management tools or libraries are added additional cryptography.
Customer HMI Developers have noticed immediately that these profiles do not contain any classes related to user interfaces. Thus, for applications using to Swing or AWT classes, you will have to go through the full JRE.
### Practice place
The theory around Java 8 Profiles assimilated, developers need tools to be able to develop applications based on them. In indeed, it's hard to remember which API is in which Profile Compact. To help developers leverage profiles and foster at best adoption, Java 8 provides 1 command line tool specific named jdeps and adds options dedicated to the compiler javac.
At the compilation of a program it is now possible to use the -profile option to tell the compiler to generate a error if the program uses classes of a higher profile. Here we can specify that our MyProg program is limited to using the compact profile1:-
## javac -profile compact1 MyProg.java
Newly added with Java 8, jdeps is a static analysis tool that performs a dependency analysis of a specific class or a JAR file. Besides the fact that it allows to know the dependencies in look at a profile, the tool is also very useful with its option - profile (or its shortcut -P) indicating which profile depend on the packages.
We can for example analyze the dependencies of the demo HMINotepad.jar included with the JDK:
$ jdeps demo/jfc/Notepad/Notepad.jar
demo/jfc/Notepad/Notepad.jar -> /usr/java/jre/lib/rt.jar
(Notepad.jar)
-> java.awt
-> java.awt.event
-> java.beans
-> java.io
-> java.lang
-> java.net
-> java.util
…
In order to know which profile the Notepad.jar dependencies belong to,
the following command line will be used:
$ jdeps -profile demo/jfc/Notepad/Notepad.jar
demo/jfc/Notepad/Notepad.jar -> /usr/java/jre/lib/rt.jar (Full JRE)
(Notepad.jar)
-> java.awt Full JRE
-> java.awt.event Full JRE
-> java.beans Full JRE
-> java.io compact1
-> java.lang compact1
-> java.net compact1
-> java.util compact1
-> java.util.logging compact1
-> javax.swing Full JRE
…
The jdeps utility takes a large number of input parameters allowing it to be flexible and adapt to a large number of use cases. Developers who want to use Compact profiles will not be able to quickly do without it.
To end a word about the support by IDE of these rotating tools around the profiles of Java 8. Developed by Oracle, the NetBeans IDE in version 8.0 logically supports a wide range of new features of Java 8. Thus, Compact profiles are no exception to the rule.
When configuring a project, the IDE allows you to select in look at which profile it should be compiled. It then becomes easier to target a particular profile and check classes with dependencies unwanted to other profiles. Of course, it remains possible to select a standard compilation by targeting a full JRE. A support of the same type is planned in future releases of Java tools for Eclipse.
Conclusion
First stop on the long road leading to the modularization of the JDK, the Compact profiles of Java 8 represent a significant step for the future of the platform. Reduce the size of the JDK and its memory footprint fundamental to improving the performance of Java applications whether embedded, desktop or server.
The next step will be that of the implementation of the project Jigsaw within Java 9 with modularization fully supported. Nevertheless, the clock is ticking and 2016 is here. Recent hesitations as to the direction that must take the project leave some doubt about taking into account from Java 9! Case to follow ...
Posted on Utopian.io - Rewarding Open Source Contributors