Performance improvements with new methods in Java 11

 

Java 11 is an upgrade over Java 8. The only direction for software depending on this JDK 8 is forward to 11. There have been new methods added and some modifications to existing API which improve startup, performance and memory usage.

While this article talks about high level changes between 8 and 11, it elaborates on the transition between 8 to 11. 

1) Java 11 supports modules. A module is a collection of classes, interfaces and resources. This reduces the footprint for the application and improves the customization of the runtime. The class loading is improved. The dependencies described by the developer for building the application become better encapsulated, secure and easier to maintain.

2) It includes better memory management and a low overhead heap profiler. Developers familiar with the Java mission control to view the memory usage find this an improvement over that available in 8.

3) Java 11 has common logging system and a flight recorder that gathers data from a running Java application. The data can then be analyzed using the Java Mission Control. 

4) The Garbage collection has four options – serial, parallel, garbage-first and epsilon with the third being the default garbage collector in Java 11. The default is usually good enough for most application however mission critical applications find the advanced features very useful.

When transitioning from Java 8 to Java 11, an application encounters a few deprecated APIs, changes to class loaders, and changes to garbage collection. Yet an application that successfully compiles against the jdk 11 can continue to run on JRE with Java 8. Leveraging the new methods and features in Java 11 only improves the execution, performance and security. 

A variety of tools serve to inspect the code prior and post this transition.  The ‘jdeprscan’ tool looks for the use of deprecated or removed API. The `jdeps` tool analyzes the dependencies of the java application. The –jdk-internals option used with jdeps can inform the usage of internal apis that are subject to change with the transition. The Java dependency analysis tools has recommended replacements for commonly used JDK internal APIs. The Java compiler itself informs quite a bit with –debug option. As with the compiler, the jdeps and jdeprscan can only report warnings based on compilation. Runtime dependencies and reflection are excluded. The –add-opens and –add-reads option can be used to expose the encapsulated packages to the compiler. The best thing about Java 11 for packaging of code is that it can support multiple-releases.  A multi-release jar is one that can support both Java 8 and Java 11. The “Multi-Release: true” directive in the jar section of the build script is usually sufficient for this purpose leading to a versioned directory in the form of “META-INF/version/N”

Most tools and particularly the java compiler have a lot of options that tweak the behavior of the tool. The Java compiler is specially used with these options to suit the needs for building the application. The JaCoLine tool helps detect problems with the command line options.