5 Features in Java 9 that WILL Change How You Develop Software (and 2 That Won’t)
What are the most exciting features that are expected to be released in Java 9?
Don’t get distracted by the relative silence lately around Java 9. The JDK committers are hard at work preparing the next release, expected to be feature complete just a few months away on December 2015. After that, it will go through rigorous tests and bug fixes preparing it for general availability, which is scheduled for September 2016.
Today we have a pretty clear picture of the features we can expect in Java 9. If Java 8 could be described as the major release of lambdas, streams and API changes, then Java 9 is all about Jigsaw, extra utilities and changes under the hood. In this post we’ve gathered some of the features we believe are the most exciting ones that are targeting Java 9 – Apart from the usual suspect, project Jigsaw, which took on the mission of breaking down the JRE and bringing modularity to Java’s core components.
Here some of the features which are an absolute must to know about in Java 9, some of these are already ready for you to tinker with in the early release version.
1. Java + REPL = jshell
Yes. Previously we had doubts that project Kulla would make it in time for Java 9 but now it’s official. The next release of Java will feature a new command line tool called jshell that will add native support and popularize a Java way to REPL (Read-Eval-Print-Loop). Meaning, say, if you’ll want to run a few lines of Java on their own you won’t have to wrap it all in a separate project or method. Oh and semicolons – you can forget about those:
-> 2 + 2 | Expression value is: 4 | assigned to temporary variable $1 of type int
There are some alternatives like REPL add-ons to popular IDEs and solutions like the Java REPL web console, but no official and right way to do this so far. jshell is already available in the early release and waiting for you to give it a test run.
2. Microbenchmarks are coming
The Java Microbenchmarking Harness (JMH) by Alexey Shipilev is taking the next step in its evolution and joins Java as an official benchmarking solution. We really love doing benchmarks here at Takipi, so a standardized way of performing them is something we look forward to.
JMH is a Java harness for building, running, and analysing nano/micro/milli/macro benchmarks. When it comes to accurate benchmarking, there are forces in play like warmup times and optimizations that can have a big impact on results. Especially when you’re going down to micro and nano seconds. So today JMH is your best choice if you want to get the most accurate results to help you reach the right decision following your benchmarks – And now it’s becoming a synonym with Java 9.
3. Will G1 be the new default garbage collector?
A common misconception we often hear is that Java has only one garbage collector when in fact it has 4. With Java 9, there’s a running proposal that’s still in debate to replace the default garbage collector (The parallel / Throughput collector) with G1 which was introduced in Java 7. For a bite sized overview about the differences between the different collectors, you can check out this post right here.
Generally, G1 was designed to better support heaps larger than 4GB and has been known to cause less frequent GC pauses, but when a pause do comes, it tends to be longer. Recently we’ve discussed all things GC with Haim Yadid, head of performance at Outbrain, to help you learn more about the different trade offs between the collectors. Also, if you’d like to have an inside view of this debate, the hotspot-dev and jdk9-dev mailing lists are a great place to start.
4. HTTP 2.0 is the future
The official HTTP 2.0 RFC was approved just a few months ago, building on top of Google’s SPDY algorithm. SPDY has already shown great speed improvements over HTTP 1.1 ranging between 11.81% to 47.7% and its implementation already exists in most modern browsers.
Java 9 will have full support for HTTP 2.0 and feature a new HTTP client for Java that will replace HttpURLConnection, and also implement HTTP 2.0 and websockets.
5. The process API just got a huge boost
So far there has been a limited ability for controlling and managing operating system processes with Java. For example, in order to do something as simple as get your process PID in earlier versions of Java, you would need to either access native code or use some sort of a magical workaround. Moreover, it would require a different implementation for each platform to guarantee you’re getting the right result.
In Java 9, expect the code for retrieving Linux PIDs, that now looks like this:
public static void main(String[] args) throws Exception { Process proc = Runtime.getRuntime().exec(new String[]{ "/bin/sh", "-c", "echo $PPID" }); if (proc.waitFor() == 0) { InputStream in = proc.getInputStream(); int available = in.available(); byte[] outputBytes = new byte[available]; in.read(outputBytes); String pid = new String(outputBytes); System.out.println("Your pid is " + pid); } }
To turn into something like this (that also supports all operating systems):
System.out.println(“Your pid is ” + Process.getCurrentPid());
The update will extend Java’s ability to to interact with the operating system: New direct methods to handle PIDs, process names and states, and ability to enumerate JVMs and processes and more.
What you’ll not be seeing in Java 9?
Two interesting features that we assumed will make a part of the upcoming Java release – but now we know they will be skipped this time are.
1. A standardized lightweight JSON API
On a survey we conducted with 350 developers, the JSON API was just as hyped as Jigsaw but looks like it didn’t make the cut due to funding issues. Mark Reinhold, chief architect of the Java platform, on the JDK 9 mailing list:
“This JEP would be a useful addition to the platform but, in the grand scheme of things, it’s not as important as the other features that Oracle is funding, or considering funding, for JDK 9. We may reconsider this JEP for JDK 10 or a later release. ”
2. Money and Currency API
In other news, it also looks like the expected Money and Currency API is also lacking Oracle support. This is the answer we got from Anatole Tresch, the APIs spec lead:
https://twitter.com/atsticks/status/610833131067846656
Reference: | 5 Features in Java 9 that WILL Change How You Develop Software (and 2 That Won’t) from our JCG partner Alex Zhitnitsky at the Takipi blog. |
I didnt see any kind of feature really revolutionary, most of those are available at Scala platform and others. Is java on a good fit for next 20 years? Only time will answer but there are several big players in the market trying to take Java share I can cite for example Node.js and others.
I would say java and node target two completely different markets. You don’t see any massive applications being written in node. From a debugging and analysis point of view node is so far behind. The REPL functionality is nothing revolutionary either and is possible with previous versions now they are more standardizing it. HTTP 2.0 libraries are already available and in use. The process API is also nice but nothing you could not do before hand with JNI. I think most of the work in java 9 is about the splitting up of the packages more then anything which is… Read more »
Thank you for article.
I think you should add value type to your list.
IMO the only feature that WILL change the way to develop software is the modularization (a.k.a. Jigsaw) and it is only mentioned briefly in the article, I was expecting 5 features describing this new feature or some kind of OSGi comparison. Information about Money API don’t get developed was new for me, thanks.
I think that with the browser being the ubiquitous delivery mechanism for apps Java better resolve the issue of a deprecated NPAPI and look at something like PPAPI real-quick! Now, for Java 8. I found out that Firefox isn’t supporting Java in the latest 64-bit builds. And Microsoft’s Spartan browser is not likely to support Java. Chrome already dumped Java last year. It looks like Iced-tea supports PPAPI – What is the hold-up?
What’s the point of native client apps in the browser? Let Java Applets die (not that they were ever alive) with the NPAPI! Java was never fit for that, even though they tried to hide it with Java FX. Silverlight is not supported any more (not even in Microsoft’s Edge browser). Flash will be dead soon. Why would Java waste effort to support an outdated paradigm? Java’s strength was always the enterprise so let’s focus on maintaining that strength!
I’m waiting to get these cool changes to test them.