26 new Java 9 enhancements you will love

• Heap space efficiencies
• Memory allocation
• Compilation process improvements
• Type testing
• Annotations
• Automated runtime compiler tests
• Improved garbage collection

26 Java 9 enhancements you should know

1. Improved Contended Locking [JEP 143]

The general goal of JEP 143 was to increase the overall performance of how the JVM manages contention over locked Java object monitors. The improvements to contended locking were all internal to the JVM and do not require any developer actions to benefit from them. The overall improvement goals were related to faster operations. These include faster monitor enter, faster monitor exit, and faster notifications.

2. Segmented code cache [JEP 197]

The segmented code cache JEP (197) upgrade was completed and results in faster, more efficient execution time. At the core of this change was the segmentation of the code cache into three distinct segments--non-method, profiled, and non-profiled code.

3. Smart Java compilation, phase two [JEP 199]

The JDK Enhancement Proposal 199 is aimed at improving the code compilation process. All Java developers will be familiar with the javac tool for compiling source code to bytecode, which is used by the JVM to run Java programs. Smart Java Compilation, also referred to as Smart Javac and sjavac, adds a smart wrapper around the javac process. Perhaps the core improvement sjavac adds is that only the necessary code is recompiled.

[box type="shadow" align="" class="" width=""]Check out this tutorial to know how you can recognize patterns with neural networks in Java.[/box]

4. Resolving Lint and Doclint warnings [JEP 212]

Both Lint and Doclint report errors and warnings during the compile process. Resolution of these warnings was the focus of JEP 212. When using core libraries, there should not be any warnings. This mindset led to JEP 212, which has been resolved and implemented in Java 9.

5. Tiered attribution for javac [JEP 215]

JEP 215 represents an impressive undertaking to streamline javac's type checking schema. In Java 8, type checking of poly expressions is handled by a speculative attribution tool. The goal with JEP 215 was to change the type checking schema to create faster results. The new approach, released with Java 9, uses a tiered attribution tool. This tool implements a tiered approach for type checking argument expressions for all method calls. Permissions are also made for method overriding.

6. Annotations pipeline 2.0 [JEP 217]

Java 8 related changes impacted Java annotations but did not usher in a change to how javac processed them. There were some hardcoded solutions that allowed javac to handle the new annotations, but they were not efficient. Moreover, this type of coding (hardcoding workarounds) is difficult to maintain.

So, JEP 217 focused on refactoring the javac annotation pipeline. This refactoring was all internal to javac, so it should not be evident to developers.

7. New version-string scheme [JEP 223]

Prior to Java 9, the release numbers did not follow industry standard versioning--semantic versioning. Oracle has embraced semantic versioning for Java 9 and beyond. For Java, a major-minor-security schema will be used for the first three elements of Java version numbers:

• Major: A major release consisting of a significant new set of features
• Minor: Revisions and bug fixes that are backward compatible
• Security: Fixes deemed critical to improving security

8. Generating run-time compiler tests automatically [JEP 233]

The purpose of JEP 233 was to create a tool that could automate the runtime compiler tests.

The tool that was created starts by generating a random set of Java source code and/or byte code. The generated code will have three key characteristics:

• Be syntactically correct
• Be semantically correct
• Use a random seed that permits reusing the same randomly-generated code

9. Testing class-file attributes generated by Javac [JEP 235]

Prior to Java 9, there was no method of testing a class-file's attributes. Running a class and testing the code for anticipated or expected results was the most commonly used method of testing javac generated class-files. This technique falls short of testing to validate the file's attributes.

The lack of, or insufficient, capability to create tests for class-file attributes was the impetus behind JEP 235. The goal is to ensure javac creates a class-file's attributes completely and correctly.

10. Storing interned strings in CDS archives [JEP 250]

CDS archives now allocate specific space on the heap for strings:



The string space is mapped using a shared-string table, hash tables, and deduplication.

11. Preparing JavaFX UI controls and CSS APIs for modularization [JEP 253]

Prior to Java 9, JavaFX controls as well as CSS functionality were only available to developers by interfacing with internal APIs. Java 9's modularization has made the internal APIs inaccessible. Therefore, JEP 253 was created to define public, instead of internal, APIs.

This was a larger undertaking than it might seem. Here are a few actions that were taken as part of this JEP:

• Moving javaFX control skins from the internal to public API (javafx.scene.skin)
• Ensuring API consistencies
• Generation of a thorough javadoc

12. Compact strings [JEP 254]

The string data type is an important part of nearly every Java app. While JEP 254's aim was to make strings more space-efficient, it was approached with caution so that existing performance and compatibilities would not be negatively impacted.

Starting with Java 9, strings are now internally represented using a byte array along with a flag field for encoding references.

13. Merging selected Xerces 2.11.0 updates into JAXP [JEP 255]

Xerces is a library used for parsing XML in Java. It was updated to 2.11.0 in late 2010, so JEP 255's aim was to update JAXP to incorporate changes in Xerces 2.11.0.

14. Updating JavaFX/Media to a newer version of GStreamer [JEP 257]

The purpose of JEP 257 was to ensure JavaFX/Media was updated to include the latest release of GStreamer for stability, performance, and security assurances. GStreamer is a multimedia processing framework that can be used to build systems that take in media from several different formats and, after processing, export them in selected formats.

15. HarfBuzz Font-Layout Engine [JEP 258]

Prior to Java 9, the layout engine used to handle font complexities; specifically, fonts that have rendering behaviors beyond what the common Latin fonts have. Java used the uniform client interface, also referred to as ICU, as the defacto text rendering tool. The ICU layout engine has been depreciated and, in Java 9, has been replaced with the HarfBuzz font layout engine.

HarfBuzz is an OpenType text rendering engine. This type of layout engine has the characteristic of providing script-aware code to help ensure text is laid out as desired.

16. HiDPI graphics on Windows and Linux [JEP 263]

JEP 263 was focused on ensuring the crispness of on-screen components, relative to the pixel density of the display. The following terms are relevant to this JEP and are provided along with the below listed descriptive information:

• DPI-aware application: An application that is able to detect and scale images for the display's specific pixel density
• DPI-unaware application: An application that makes no attempt to detect and scale images for the display's specific pixel density
• HiDPI graphics: High dots-per-inch graphics
• Retina display: This term was created by Apple to refer to displays with a pixel density of at least 300 pixels per inch

Prior to Java 9, automatic scaling and sizing were already implemented in Java for the Mac OS X operating system. This capability was added in Java 9 for Windows and Linux operating systems.

17. Marlin graphics renderer [JEP 265]

JEP 265 replaced the Pisces graphics rasterizer with the Marlin graphics renderer in the Java 2D API. This API is used to draw 2D graphics and animations.

The goal was to replace Pisces with a rasterizer/renderer that was much more efficient and without any quality loss. This goal was realized in Java 9. An intended collateral benefit was to include a developer-accessible API. Previously, the means of interfacing with the AWT and Java 2D was internal.

18. Unicode 8.0.0 [JEP 267]

Unicode 8.0.0 was released on June 17, 2015. JEP 267 focused on updating the relevant APIs to support Unicode 8.0.0.

In order to fully comply with the new Unicode standard, several Java classes were updated. The following listed classes were updated for Java 9 to comply with the new Unicode standard:

• java.awt.font.NumericShaper
• java.lang.Character
• java.lang.String
• java.text.Bidi
Unlock access to the largest independent learning library in Tech for FREE!
Get unlimited access to 7500+ expert-authored eBooks and video courses covering every tech area you can think of.
Renews at AU $24.99/month. Cancel anytime
START FREE TRIAL
• java.text.BreakIterator
• java.text.Normalizer

19. Reserved stack areas for critical sections [JEP 270]

The goal of JEP 270 was to mitigate problems stemming from stack overflows during the execution of critical sections. This mitigation took the form of reserving additional thread stack space.

[box type="shadow" align="" class="" width=""]Are you looking out for running parallel data operations using Java streams, check out this post for more details.[/box]

20. Dynamic linking of language-defined object models [JEP 276]

Java interoperability was enhanced with JEP 276. The necessary JDK changes were made to permit runtime linkers from multiple languages to coexist in a single JVM instance. This change applies to high-level operations, as you would expect. An example of a relevant high-level operation is the reading or writing of a property with elements such as accessors and mutators.

The high-level operations apply to objects of unknown types. They can be invoked with INVOKEDYNAMIC instructions. Here is an example of calling an object's property when the object's type is unknown at compile time:

  INVOKEDYNAMIC "dyn:getProp:age"

21. Additional tests for humongous objects in G1 [JEP 278]

One of the long-favored features of the Java platform is the behind the scenes garbage collection. JEP 278's focus was to create additional WhiteBox tests for humongous objects as a feature of the G1 garbage collector.

22. Improving test-failure troubleshooting [JEP 279]

For developers that do a lot of testing, JEP 279 is worth reading about. Additional functionality has been added in Java 9 to automatically collect information to support troubleshooting test failures as well as timeouts. Collecting readily available diagnostic information during tests stands to provide developers and engineers with greater fidelity in their logs and other output.

23. Optimizing string concatenation [JEP 280]

JEP 280 is an interesting enhancement for the Java platform. Prior to Java 9, string concatenation was translated by javac into StringBuilder : : append chains. This was a sub-optimal translation methodology often requiring StringBuilder presizing.

The enhancement changed the string concatenation bytecode sequence, generated by javac, so that it uses INVOKEDYNAMIC calls. The purpose of the enhancement was to increase optimization and to support future optimizations without the need to reformat the javac's bytecode.

24. HotSpot C++ unit-test framework [JEP 281]

HotSpot is the name of the JVM. This Java enhancement was intended to support the development of C++ unit tests for the JVM. Here is a partial, non-prioritized, list of goals for this enhancement:

• Command-line testing
• Create appropriate documentation
• Debug compile targets
• Framework elasticity
• IDE support
• Individual and isolated unit testing
• Individualized test results
• Integrate with existing infrastructure
• Internal test support
• Positive and negative testing
• Short execution time testing
• Support all JDK 9 build platforms
• Test compile targets
• Test exclusion
• Test grouping
• Testing that requires the JVM to be initialized
• Tests co-located with source code
• Tests for platform-dependent code
• Write and execute unit testing (for classes and methods)

This enhancement is evidence of the increasing extensibility.

25. Enabling GTK 3 on Linux [JEP 283]

GTK+, formally known as the GIMP toolbox, is a cross-platform tool used for creating Graphical User Interfaces (GUI). The tool consists of widgets accessible through its API. JEP 283's focus was to ensure GTK 2 and GTK 3 were supported on Linux when developing Java applications with graphical components. The implementation supports Java apps that employ JavaFX, AWT, and Swing.

26. New HotSpot build system [JEP 284]

The Java platform used, prior to Java 9, was a build system riddled with duplicate code, redundancies, and other inefficiencies. The build system has been reworked for Java 9 based on the build-infra framework. In this context, infra is short for infrastructure. The overarching goal for JEP 284 was to upgrade the build system to one that was simplified. Specific goals included:

• Leverage existing build system
• Maintainable code
• Minimize duplicate code
• Simplification
• Support future enhancements

Summary

We explored some impressive new features of the Java platform, with a specific focus on javac, JDK libraries, and various test suites. Memory management improvements, including heap space efficiencies, memory allocation, and improved garbage collection represent a powerful new set of Java platform enhancements. Changes regarding the compilation process resulting in greater efficiencies were part of this discussion We also covered important improvements, such as with the compilation process, type testing, annotations, and automated runtime compiler tests.

You just enjoyed an excerpt from the book, Mastering Java 9 written by By Dr. Edward Lavieri and Peter Verhas.