Java 9 is here, and it’s time to go over what’s about to change, and what you should do about it
[Update 7-Feb-2018: Java 9 is here and is expected to revolutionize the way we think of and build large scale applications. Our Java 9 First Impressions webinar explores how.]
In the following post, we’ve bundled some of the new features that you should be aware of and see how they may (or may not) affect the way we write code. Buckle your seatbelt, here’s our checklist for JDK 9:
— OverOps (@overopshq) May 4, 2017
1. Meet the Default Garbage Collector
Java 9 comes with Garbage First Garbage Collector (G1 GC) as its default garbage collector (although we can still switch it if we really want to).
G1 is a server-style garbage collector, designed for multi-processor machines with large memories. There are a number of differences between it and other garbage collectors, that include serial, parallel and CMS, and we’ve already covered some of them in a previous post.
To give you a quick review, we’ll focus on one of the main differences between the collectors – structure. Since Java 8, garbage collectors divided the heap into 2 sections:
- Young generation – where all new objects are allocated and aged
- Old generation – used to store long surviving objects
(and up until Java 8, there was a third section of Permanent generation, that contained metadata required by the JVM to describe the classes and methods used in the application).
With G1, the heap is partitioned into a set of equal-sized heap regions, each a contiguous range of virtual memory. G1 supports heaps larger than 4GB, and is a parallel, concurrent, and incrementally compacting low-pause garbage collector.
G1 is already supported in JDK 7 and 8, so you can try it right now and see if it suits your application. If you don’t like changes, or simply prefer one of the old garbage collectors, don’t worry. You’ll still be able to set your garbage collector of choice as part of the JVM startup arguments, so it will not be affected by this change.
2. Jigsaw is Here!
Project Jigsaw feels like somewhat of a synonym for the word “Delayed”. The project has a history of pushing back Java versions, starting from Java 7, moving to Java 8 and, now, finally being released in Java 9.
It’s no wonder, due to the complexity of the project. Jigsaw aims to make Java modular and break the JRE to interoperable components. This means that you’ll be able to create a scaled down runtime Jar (rt.jar) customized to the components a project actually needs.
This project aims to make Java scalable to small computing devices, improve security and performance, and mainly make it easier for developers to construct and maintain libraries.
It’s a critical and important project, and as such it was bound to have a few setbacks and delays. The final delay came from IBM and Red Hat, both are members of the Java Community Process Executive Committee (JCP), that voted No on the project.
The two companies stated their dissatisfaction with the current state of project Jigsaw, when Scott Stark, Vice President of Architecture at Red Hat pointed out that “we have raised a number of concerns regarding the implementation decision in Jigsaw, as well as the scope and consensus of the expert group efforts”.
Stark signed his email off by saying that “As it stands, Red Hat will not vote for the approval of this public review draft of JPMS (Java Platform Module System) as it is not in the best interest of the Java community”.
Tim Ellison, Senior Technical Staff Member at IBM, joined the decision and published that “IBM is also voting “no”, which reflects our position that the JSR (Java Specification Request) is not ready at this time to move beyond the Public Review stage and proceed to Proposed Final Draft”.
3. Unsafe is now an Official Part of Java 9
sun.misc.Unsafe is one of the key APIs in the JVM since Java 6, but it was intended to be only used by core Java classes, and not the developers themselves. How do we know? Since the only constructor it had was made private, and so did its singleton instance.
The library itself is a collection of methods for performing low-level, unsafe operations. We know, the title gives it away. One of the uses for this library is using the allocate Instance method for skipping the object initialization phase or to bypass security checks in a constructor.
However, “The afternoon knows what the morning never suspected.” Numerous libraries started using Unsafe, and it became a key library for many projects. Since it’s unsafe, Oracle planned on removing it altogether.
Donald Smith, Senior Director of Product Management at Oracle, stated that “sun.misc.Unsafe must die in a fire. It is — wait for it — Unsafe. It must go.” Ouch. As you can imagine, the Java community didn’t take it so well and protested against this decision.
It took a while but eventually, the community won – and are about to get Unsafe encapsulated in Java 9. To make it safe, the functionality of many of the methods in this class will be available via variable handles.
Java 9 is about to introduce JShell, the first official Java REPL (Read-Eval-Print-Loop). Up until now, there was no “native” way to REPL in Java. What does it actually mean? If we wanted to run a few lines of Java to check them out quickly on their own, we had to wrap them in a separate project or method.
The ability to evaluate code snippets such as declarations, statements, and expressions was available through alternative solutions (Java REPL web console being one of them), but JShell adds that native and official support.
In other words, we’ll now be able to test small snippets of our code as soon as we write them, without having to finish the entire project. If you want to try it out today, check out our JShell hands-on review.
Fun fact: Oracle points out that JShell was created as a result of academic feedback. Schools adopt languages that have REPL functionality since it helps lower the initial learning curve of programming.
5. New and Interesting Language Changes
There are a few enhancements to core libraries in JDK 9, and we’ve decided to focus on the top changes. The first one is the Stack-Walking API, which introduces an official way to process stack traces. This class includes methods that go over the stack and will provide us with an overview of the current thread, at any point we’re interested seeing.
In other words, the Stack-Walking API will change the way you traverse stack traces. If you want to learn more about this new feature and see what we thought of it, check out our complete overview here.
Java 9 will also introduce the java.util.concurrent.Flow library, that will include interfaces supporting the Reactive Streams publish-subscribe framework, nested within the new class Flow. Check out our deeper look into this class and the changes it brings.
Other libraries that will be updated are the Process API, that will improve controlling and managing operating system processes, Compact Strings that will offer a more space-efficient internal representation for strings and Enhanced Deprecation, revamping the @Deprecated annotation to provide better information about the status and intended disposition of an API in the specification
Java 9 will also include a set of a set of small language changes as part of Project Coin, Removal (that begun in Java 8) of underscore from the set of legal identifier names, and support for private interface methods.
This is just a small list of the changes about to come, and you can check out the full official list, as made by Oracle, here.
Java 9 is about to rock the boat, and we can’t be any more excited about it. However, while it might be tempting to start using it the day it’s officially out, we recommend you check what needs to be done in your environment and code before you start using it. Or as Ice Cube once said, you better check yourself before you wreck yourself. It’s better to be safe than sorry, especially when it comes to code.
If you’re an early adopter, or just can’t wait to try out Java 9, you can check it out right now.