Java 9 to 11 and SmartFoxServer 2X

In this article we’re going to take a quick tour of the fundamental changes that Java releases 9 through 11 have introduced, their implications for development, deployment and how SmartFoxServer 2X will move forward in relation to the new and faster cycles of Java releases.

» Java 9, where it all started

After three years since the launch of Java 8 the long awaited JDK 9 was finally released bringing several significant revolutions to the platform such as:

  • Modularity
  • Faster release cycles
  • Multiple distributions and support plans

While the list of Java 9 new features was quite extensive the three items above have special implications on almost all aspects of an application life cycle, from coding to deployment to maintenance.

Modularity

The Java runtime has notably been monolithic since its inception back in 1996, in fact we can find most of the 4500+ classes that comprise the JDK inside the infamous rt,jar file located under jre/bin/lib/, which these days is over 60MB in size.

This in turn can make it cumbersome to provide a slim runtime for Java-based applications, especially for embedded devices where the app code can be smaller than the runtime itself.

Java 9 addresses this issue by providing a new module system, JPMS (Java Platform Module System), that allows the JRE to be very slim and offers tools for deploying custom runtimes with only the necessary modules.

More specifically the core classes of the J2SE has been split into 27 modules (under different categories) that developers can select and include in their application’s runtime and leave the rest out, to minimize overhead.

JPMS however is not just about organizing large libraries of code but it also offers new levels of encapsulation to completely hide packages that are not meant to be exposed to the outside world. This can have crucial implications when moving from a previous Java runtime to version 9 or higher.

A practical example of this is the use of reflection which is no longer allowed to hack inside any class from any package and bypass field accessibility. Because of it there have been heated debates on how modularity should work especially in relation to popular libraries such as JPA, Hibernate, Spring and similar tools that rely heavily on reflective access.

To avoid a backward compatibility earthquake, JDK 9 comes with an encapsulation kill switch, in other words it is possible to turn off all the access limitations imposed by JPMS, for the time being, and keep working as in “old Java”. However this is only temporary and eventually the kill switch will be removed and applications will need to be restructured (or rewritten) to use JPMS as intended.

Faster Release Cycles

Since the release of Java 9, Oracle has announced their intention to launch two new major JDK releases every year, typically 6 months apart (March and September).

With the faster release pacing also comes a different support model where only certain versions of the JDK will receive long term support (LTS), while others will not. LTS is a three year plan where Oracle will continue to provide patches for security issues, bug fixes etc. However, for JDKs not marked as LTS there won’t be this kind of support and the only way to get an update would be to migrate to the next major release coming six months later.

For instance JDK 8 is considered LTS and as such is going to be supported until 2020, while Java 9 and 10 are not. The latest JDK 11 is an LTS release and it will continue to be supported for the next three years.

There are also other considerations in the Oracle license that make distinctions between commercial and non commercial use that can impact the duration of the LTS terms. We’re not going to go into the details of this here, but we’ll provide links for you to learn more, if you’re interested.

Multiple distributions and support plans

The multi-distribution feature is not exactly a novelty that came with Java 9 but it’s now more relevant because different JDK binary releases come with different licenses of use.

  • Oracle JDK: is the official Java platform provided by Oracle with long term support only for selected releases and a few more restrictions for commercial uses.
  • Open JDK: is the GPL2 based Java that has no restrictions compared to Oracle’s but also does not provide LTS and therefore every release has only a 6 month window of support.
  • Other implementations: there are third party implementations of the JDK provided by companies such as RedHat, Azul, Amazon and others. Each have their pros and cons and come with their own support plans. We’ll touch on Amazon’s own JDK later in this article as it is of particular interest for SmartFoxServer.

» How is SFS2X going to handle the Java revolution?

For the past 2 years, since SFS2X 2.12, we have been embedding Java 8 as the default runtime and we don’t expect this to change for several more years.

While Java 9 through 11 offer interesting new features and changes, none of them are crucial for the development of the next features planned for SmartFoxServer 2X, therefore we don’t expect to switch to JDKs higher than 8 in the incoming future.

However, since our customers might be curious or in need to use specific features of  Java 9/10/11 we can guarantee that SFS2X will run flawlessly in all of the most recent JDKs. This way developers can simply download the server, replace the embedded JRE and they are good to go.

This comes with an important caveat: SmartFoxServer 2X will work smoothly with any JDK from 9 to 11 (and possibly beyond) provided that the encapsulation kill switch is kept turned on (which is the default mode). Since SFS2X uses reflection and depends on libraries that also use reflective access, it’s not compatible with JPMS encapsulation strict rules.

» F.A.Q.

What will happen when the kill switch is removed in a future JDK release?

Once Java finally removes the encapsulation kill switch SmartFoxServer 2X will cease to work and thus will become incompatible with specific releases of the JDK. The solution to this problem would be to rewrite substantial parts of the core services and replace different libraries that offer critical functionalities.

While this is in the realm of possibilities, the effort could easily match that of rewriting the product from scratch. Keep reading for more info on this.

Java 8 support expires soon, by January 2020. Are you not going to switch to the next LTS release of Java (a.k.a. Java 11)?

Not necessarily. While Oracle’s JDK 8 is going to be supported only for one more year (at the time of writing) Amazon’s JDK (codename “Corretto“) will continue to provide support until at least July 2023. So our plan is to stick with this release of the JRE for the time being.

Is Amazon’s JDK production ready?

Yes, it is. Corretto is built on the Java platform specifications and is meant as a drop-in replacement for another Java distribution, such as Oracle’s or OpenJDK. We’ve tested the runtime running SmartFoxServer 2X under different stress scenarios and have found it to be perfectly stable and on par with the performance of the Oracle/OpenJDK runtimes.

» Conclusions and a word to the wise

The recent updates to the Java platform provide a needed renovation of the environment, with significant improvements to the language, tools and runtime. This sets the stage for a more modern Java for the next decade, and the new fast release cycles is quickly catching up with  other big contenders such as C# and Swift.

However before jumping on the  latest Java 11 bandwagon we’d like to caution that the transition from any JDK <= 8 is not necessarily pain free. A lot of changes have been introduced in the standard API and JVM, which may impact your workflow, debugging, management and so forth.

Before deciding to switch we suggest to take some time and investigate what has changed and what libraries and tools you use may need to be upgraded or replaced.

As we have mentioned, SmartFoxServer 2X runs perfectly fine in Java 9/10/11 but your code may not and it should be tested as well, including the relative dependencies and any other tool that is part of your workflow (profilers, code obfuscators, build tools etc…)

Finally here are some in-depth resources we recommend you to consult in order to learn more:

If you have any questions or would like to discuss this topic further you can get in touch with us on our support forums.