Java8 vs Java9

Java 8 vs Java 9: Improvements in Java 9 that You Need to Know

Many developers will turn to Java to create applications. As we all know, Java is incredibly versatile, easy to use, secure, reliable and most of all, it is platform independent. Java has a following of more than 6.5 million developers globally. As such, it is the perfect language to use since reference material is also abundant.

Nevertheless, Java has continued to grow and evolve over the years. Created by Sun Microsystems in 1995, Java has continued proving its reliability. The previous build of Java that has been in use since March 18, 2014, was Java SE 8. When it was unveiled, critics said it was a work of art, a release of streams of changes in APIs. Now there is a new kid on the block. Freshly minted Java 9 is finally here. Unveiled on September 21, 2017, Java SE 9 is expected to shake up the way we do things and the way developers create applications.

Due to Java 8’s incredible agility and versatility, businesses created incredible solutions for industries such as healthcare, fintech, and other major sectors. Java 9, on the other hand, promises to build on that and deliver entirely new functionalities to the developers.

So, let’s take a look at what’s new in Java 9.

Project Jigsaw

This is one of the highlights of Java 9. Basically, project jigsaw is the name given to modularization of Java. As jigsaw pieces come together piece by piece to create one bigger picture, so does the modularity of Java 9. This means that the code is broken up into parts (modules) due to the tasks or functionalities to be executed. This is a huge step forward because modularization not only makes re-usability of code much more comfortable, but also managing and debugging is straightforward. Because of this, we find that developers are going to have an easier time creating applications with Java 9 than with any other previous builds.

Another benefit of modularization is that developers can now create lightweight, scalable applications. Especially with the Internet of Things continuing to grow, we’ll find more such apps written in Java.

JEP 222: jshell: The Java Shell

Java 9 features the new read-eval-print loop (REPL) tool. After being in its developmental phase under Project Kulia this feature has finally been released to the public. This new feature is an interactive tool that is used to test expressions, statements, and declarations written in Java. The main goal of the JShell API and tool is to give the developer a chance to test out the features mentioned above in the shell state. This is primarily fast coding and investigation, whereby the expressions and statements don’t need to be inside a method and methods in turn, don’t have to be inside a class. This way a developer can quickly analyze pieces of code and see whether they will bring the desired effect.

The jshell tool will have a command line interface with the following features:

Configurable predefined definition and imports.
A history with editing capabilities
Automatic addition of necessary terminal semicolons

Compiler improvements

To ensure applications run faster, Java 9 has enlisted a new technology called ahead-of-time (AoT) compilation. This technology albeit in its experimental phases, makes it possible for Java classes to be compiled into native code even before it’s launched in the virtual machines. The possibilities of this are endless. However, the more immediate use of this technology is improving the startup time for large and small apps without any deterrence in peak performance.

In retrospect, Java 8 uses Just-in-time (JIT) compilers. These compilers are fast but take a bit more time before warming up. That may be inconsequential for smaller programs or apps because there isn’t much code to compile. However, for the larger apps, the narrative is quite different. The warm-up a just-in-time compiler needs, means some methods are not compiled thus weakening the app’s performance.

The second phase in smart compilation deployment is the improvement of the Javac tool’s portability and stability. Enhancing this tool enables it to be used directly in the JVM (Java Virtual Machine) as the default setting. Apart from that, the tool has been generalized in such a way that allows developers to use it even outside the JDK environment. For developers this is a big deal since Java can be used in larger projects which can easily be accommodated without worrying about compatibility. Another crucial update is the backward compatibility of the Javac compiler whose sole function is to compile apps and programs created using Java 9 to also run on older Java versions.

Better JavaScript backing

As JavaScript continues to gain momentum and become a favorite for many, JDK 9 has made it possible to embed JavaScript in Java apps. All this is done with the help of Project Nashorn whose main goal was to create high performance yet lightweight JavaScript runtime in Java. This of course was delivered when they provided a JavaScript engine in JDK version 8. Now in version 9, there is a parser API whose target is the Nashorn’s ECMAScript syntax order. What this API does is to enable analysis of ECMAScript code by server-side frameworks and IDEs without having to rely on the internal implementation classes of Project Nashorn.

G1 as the garbage collector

Contrary to popular belief, Java has not one, but four garbage collectors. These garbage collectors are not created equal and as such, choosing the wrong one meant having performance issues in the application. In Java 8, the default garbage collector was the Parallel / Throughput Collector. This garbage collector has been replaced by its predecessor the Garbage-first collector (G1). Since the G1 collector was designed to support heaps larger than 4GB efficiently, it is the perfect garbage collector for both small and large-scale applications.

API updates

In this new version of Java development kit, several updates have been made to the APIs and we’ll discuss the most notable.

The very first one is the Java 9 concurrency updates which have Java.util.concurrent.Flow and CompletableFuture. Aimed at solving the problem that is back-pressure. Flow is Java’s implementation of the Reactive Streams API which essentially aims to solve the backpressure problem. Back pressure is the build-up of data that occurs when the rate of incoming requests is greater than the processing capability of the application. In the long run, this is a problem because the application ends up with a buffer of unprocessed data. This update will mean better handling of timeouts, delays, and subclassing.

Security is part of Java’s core identity. As such, support for the newly approved HTTP 2.0 RFC is a huge plus. HTTP 2.0 RFC was built on top of Google’s SPDY algorithm which has already started bearing fruit with speed improvements ranging from 11.81% to 47.7% from the previous HTTP 1.1. This client API is an upgrade to the core HTTP protocols and the HttpURLConnection API which is problematic, to say the least since it was made even before HTTP 1.

Code caching has always been a strategy used to make applications faster and smoother over the years. However, it isn’t without its limitations, and this has not gone unnoticed. An update in Java 9 clearly shows JDK 9 dividing cached codes into smaller parts thus improving overall performance. JDK 9 uses special iterators to skip non-method code; to separate profiled, non-profiled and non-method code; and improving some benchmarks for execution time.

Benefits of Java 9

To many business owners, there is no difference between Java 8 and 9. However, for the developer, there is a world of difference. These are the benefits that Java SE 9 has over its predecessors.

The speed of development will be significantly increased thanks to the system of modules which are not only easier to manage and debug, but also reusable meaning you don’t have to write the whole code from scratch.
Enhancing resource effectiveness for applications from modularization and also making resource pulling to be simpler since developers will only take the modules needed instead of whole JRE.
Real-time analysis of snippets of code such as micro benchmarks used to look into the performance of small pieces of code.