The State of Java in 2018

2017 has been a turbulent year in the Java world. The long-awaited release of Java 9 brought a lot of changes and interesting new features, and Oracle announced a new release schedule for the JDK.

And that was just the beginning. In the past, developers often complained that Java wasn’t developing fast enough. I don’t think you will hear these complaints in the near future. It might be quite the opposite.

What’s in store for 2018

In 2018, the JDK will follow a new release schedule. Instead of a huge release every few years, you will get a smaller one every six months. So, after the release of Java 9 in September 2017, Java 10 is already planned for March 2018. But more about that later.

Enterprise Stack Overview

Most enterprise projects don’t use the JDK alone. They also rely on a stack of enterprise libraries, like Spring Boot or Java EE, which will also evolve over the next several months. In this article, I will mostly focus on the JDK. But here is a quick overview of what you should expect from the two major enterprise stacks in the Java world.

The Spring development team is working hard on Spring Boot 2 and released the first release candidate in January. The team doesn’t expect any major API changes and doesn’t plan to add any new features until the final release. So, if you are using Spring Boot in your projects, it’s about time to take a closer look at the new version and to plan the updates of your existing Spring Boot applications.

At the end of 2017, Oracle started to hand over the Java EE specifications to the EE4J project managed by the Eclipse Foundation. As expected, such a transfer is a huge project which can’t be completed in a few days. There is a lot of organizational and technical work that still needs to be done. Java EE needs a new name and development process. And the transfer of the source code and all the artifacts stored in different bug trackers is still ongoing. We will have to wait a little bit longer before we can see the effects of the transfer and the stronger community participation.

Short JDK release and support cycles

As announced last year, Oracle will release two new JDK versions in 2018. Instead of the slow release cycle where every few years produced a new major release with lots of changes, we will now get a smaller feature release every six months. This allows for faster innovation of the Java platform. It also reduces the associated risks of a Java update. For Java developers, these smaller releases will also make it a lot easier to get familiar with the latest changes and to apply them to our projects.

I expect this to be a very positive change for the Java world. It will add a new dynamic to the development of the Java language, and allows the JDK team to adapt and innovate a lot faster.

Changes and new features in JDK 10

Due to the short release cycle, Java 10 only brings a small set of changes. You can get an overview of the currently included 12 JEPs (JDK Enhancement Proposal) on the OpenJDK’s JDK10 page.

The most notable change is probably the support for type inference of local variables (JEP 286). But you should also know about the new time-based release versioning (JEP 322), and parallel full GC (garbage collector) support added to G1, or Garbage First (JEP 307).

Type inference

JDK 10 will finally introduce type inference to the Java language. Most other statically-typed languages have been supporting this feature for quite a while, and a lot of Java developers have been asking for it.

JEP 286 introduces the keyword var, which shortens the declaration of a local variable. It tells the compiler to infer the type of the variable from its initializer. So, instead of:

List<String> paramNames = List.of("host.name", "host.port");
Configuration config = initializeConfig(paramNames);

you will be able to write:

var paramNames = List.of("host.name", "host.port");
var config = initializeConfig(paramNames);

As you can see in the code snippets, the keyword var removes the redundancy from the variable declaration. This can make your code easier to read, especially if you use good variable names and if it’s a variable that you only use a few times directly after you declared it.

If you want to dive deeper into JEP 286 and when you should use it, I recommend you take a look at Nicolai Parlog’s very detailed article about type inference in Java 10.

Time-based release versioning

Beginning with Java 10, the format of the Java version number changes to improve the support for a time-based release model.

The main challenge introduced by the new release model is that the content of a release is subject to change. The only thing that’s defined in the beginning is the point in time at which the new version will be released. If the development of a new feature takes longer than expected, it doesn’t make the cut for the next release and will not be included. So, you need a version number that represents the passage of time, instead of the nature of the included changes.

JEP 322 defines the format of the version number as $FEATURE.$INTERIM.$UPDATE.$PATCH, and plans to use it as follows:

• Every six months, the development team will publish a new feature release, and increment the $FEATURE part of the version number.
• The release published in March 2018 will be called JDK 10, and the one in September JDK 11. The development team states in JEP 223 that they expect to ship at least one to two significant features in each feature release.
• The $INTERIM number is kept for flexibility and will not be used in the currently planned 6-month release model. So, for now, it will always be 0.
• Updates will be released between the feature releases and shall not include any incompatible changes. One month after a feature release and after that every three months, the $UPDATE part of the version number will be incremented.

Parallel full GC in G1

For most developers, this is one of the smaller changes. Depending on your application, you might not even recognize it.

G1 became the default garbage collector in JDK 9. Its design tries to avoid full garbage collections, but that doesn’t mean that they never happen. Unfortunately, G1 only uses a single-threaded mark-sweep-compact algorithm to perform a full collection. This might result in a performance decrease compared to the previously used parallel collector.

JEP 307 addresses this issue by providing a multi-threaded implementation of the algorithm. Beginning with JDK 10, it will use the same number of threads for full collections as it applies for young and mixed collections.

So, if your application forces the garbage collector to perform full collections, JDK 10 might improve its performance.

Plans for JDK 11

JDK 10 isn’t even released yet, and there are only seven months left until the release of JDK 11. So, it’s no surprise that there is already a small set of JEPs planned for the second feature release in 2018.

In addition to the removal of deprecated Java EE and CORBA modules (JEP 320) and a new garbage collector (JEP 318), JDK 11 will most likely introduce dynamic class-file constants (JEP 309), and support the keyword var for implicitly-typed lambda expressions (JEP 323).

The current scope of JDK 11 shows the benefits of shorter release cycles. The JEPs 309 and 318 introduce new functionality, while the other two JEPs use an iterative approach to evolve existing features.

With the release of JDK 9 in September 2017, the Java EE and CORBA modules became deprecated. One year later, with the release of JDK 11, JEP 320 removes them from the JDK. So, instead of keeping them for several years, they will be removed in a timely and predictable way.

And JEP 323 is a logical next step after JEP 286 introduced type inference for local variables in JDK 10. You should expect to see this approach more often in the future. The short release cycles make it a lot easier to ship a huge feature in multiple, logical steps distributed over one or more feature releases.

Short support cycles require fast adoption

Together with the new release model, Oracle also changed their support model. The new model differentiates between short-term and long-term releases.

Short-term releases, like Java 9 and 10, will only receive public updates until the next feature release gets published. So support for Java 9 ends in March 2018, and Java 10 will not receive any public updates after September 2018.

Java 11 will be the first long-term release. Oracle wants to support these releases for a more extended period. But until now, they didn’t announce how long they will provide public updates for Java 11.

As an application developer, you will need to decide if you want to update your Java version every six months, or if you prefer a long-term release every few years. In addition to that, Oracle encourages everyone to migrate to their Java SE Advanced product. It includes at least five years of support for every long-term release.

Summary

In the past, a lot of developers complained about the slow evolution of the Java language. That will no longer be the case in 2018. The new, 6-month release cycle and the adapted support model will enforce faster updates of existing applications and introduce new features on a regular basis. In combination with the evolution of existing frameworks, like Java EE or Spring, this will add a new dynamic to the Java world. And it will also require a mindset shift in all companies that are used to updating their applications every few years.

With APM, server health metrics, and error log integration, improve your application performance with Stackify Retrace.  Try your free two week trial today

Author

Thorben

More articles by Thorben