Here at IDRsolutions we are very excited about Java 9 and have written a series of articles explaining some of the main features. In our previous Java 9 series article we looked at Javadocs in Java 9. This time we will be looking at some of the hidden features you might have missed.
As you know Java 9 has been announced to be feature complete for some time. Since then discussions of the various features have been discussed since then taking place. With the release of Java 9 coming ever closer I thought it was time to go over some features that appear to get discussed less often. So here is my pick of 4 hidden features in Java 9.
JEP 102: Process API updates
JEP 102 proposes to improve the way operating system processes are handled.
This JEP affects 3 classes, these are, an update to Process and the introduction of ProcessHandle and ProcessHandle.Info.
Improvements to the Process class allow you to get the Pid for the Process and to retrieve a ProcessHandle object for this Process, ProcessHanlders object for its descendants, or a ProcessHandler.Info object for the current process.
ProcessHandle allows the us to perform actions on and check the state of the Process it relates. The ProcessHandle allows you to perform the following actions
- Return a ProcessHandle.Info containing further information about the Process
- The Pid of the Process
- If it is alive
- Retrieve a snapshot of the direct children of the Process
- Retrieve a snapshot of all the descents of the Process
- Retrieve a snapshot of all currently running Processes
- Allow the Process to be destroyed (or forcibly destroyed)
- Return a completableFuture with a ProcessHandle for when the Progress is terminated
The ProcessHandle.Info holds information from a snapshot of the process, this can include
- Command of the Process
- Arguments of the Process
- Command line of the Process (combination of Command and Arguments)
- Start time of the Process
- CPU time used by the Process
- User of the Process
Previously many of these functions would need to be performed in platform specific ways but now we have an API that makes the interaction much simpler and cleaner.
JEP 295: Ahead-of-Time Compilation
JEP 295 proposes to allow Ahead-Of-Time (AOT) compiling.
The JVM uses uses a Just-In-Time (JIT) compiler. When you compile your Java application it is compiled to bytecode which the JVM can interprets using the JIT compiler.
JIT compilation also has an extra step, when a method is reaches certain criteria, such as being called often, the bytecode can be compiled to machine code. This additional compilation is to aid performance of the application.
AOT compiling allows you to create shared libraries, these are classes that have been compiled to machine code. When you want to run the application you can specify shared libraries to be used. The application can then check the shared libraries for compiled code it can use instead of interpreting the bytecode.
Whilst incredibly useful it may not be usable for everyone due to the fingerprinting used to ensure the shared library can be used.
When the shared library is created a fingerprint is added to the library for each class to identify it to the class as bytecode. So changing the class will alter the fingerprint and the AOT compiled class will no longer match so it will not be used. The Java version is also stored in the shared libraries and checked when loading, this means shared libraries are tied to individual Java versions as well and must match for it to be used. Useful if you can control the version of Java being used.
JEP 213: Milling Project Coin
JEP 213 proposes 5 amendments but I wanted to focus on just one of these. Number 5, Support for private methods in interfaces.
Before Java 8 interfaces could not contain methods, they only allowed you to define method signatures which you then implement elsewhere. Then with Java 8 static and default methods were introduced to interfaces, both of which are public. This allow you to place methods in the interface to either access statically or to be used as a default implementations of the method if it is not overridden in the interface implementations.
With the introduction of private methods we can tidy up how we use these methods, for instance any duplicate code across these methods can be placed in a private method to shorten the methods. This will make maintenance and changes easier to do and without having to include another public method. Whilst this is not the biggest change in Java 9 I feel it is completing a feature that was started in Java 8 and worth mentioning.
JEP 251: Multi-Resolution Images
JEP 251 proposes that introduction of an object to be used to display one of multiple images based on resolution.
The idea here is that can store an image set composes of the same image at different resolutions in an implementation of MultiResolutionImage. Then when it is used by a Graphics object the resolution that best fits the transformations and display settings of the available images is used. Hopefully it will become immediately obvious how useful this functionality could be. In an application where the display areas scaling may change for instance.
Using this feature allows the Graphics object to receive an image close to the correct dimensions required. Then it can apply a more subtle scaling causing less distortion that can be caused by larger scaling values. Whilst you could still implement your own system to manage using different sized images, this approach keeps it internal to the draw code and removes the need to swap out the images being used yourself.
Do you have a hidden gem from Java 9 or just a feature you feel hasn’t been discussed enough? Feel free to tell us about it in the comments.
Latest posts by Kieran France (see all)
- 4 Hidden Features in Java 9 - May 30, 2017
- Why HTTP/2 Client in Java 9 is important - May 23, 2017
- PDF Portfolio support added to JPedal, so what are they? - April 4, 2017
- Our Goals for the JPedal Java PDF Library SDK in 2017 - December 16, 2016
- Annotations in PDF Files, what are they and why use them? - July 27, 2016