Core Java

Thinking of Java 10 and beyond

Hello once again. Java 10 was released on 20th March 2018. I think many software teams will hold back from upgrading to it. Even lesser numbers of professional probably still have yet to make a move from Java 8 to Java 9. Why would this be the case, because of legacy impediments and dependencies on application servers, frameworks and even cloud native containers. For instance, if you are waiting for Spring Boot 2.0 support, then Pivotal has released this open source software foundation. At the time of writing, April 2018, you will probably are not going to take your SpringBoot 2.0 application to the Pivotal Cloud Foundry, although the latest BuildPack does state it supports OpenJDK 9.

What lies behind the lack of adoption of Java 9 by enterprise customers?

  • Some people blame Oracle for the lack of adoption of Java 9 and Jigsaw. Why? Because Java 9 had only 6 months of commercial support.
  • Java 9 was publicly released on September 2017 and the official ran out on the 20th March 2018. That’s exactly correct. On the day that Java 10th was released.
  • Java 10 was publicly released on 20th March 2018 and it’s public update support with end in about 6 months when Java 11 is expected to be released.

So what to do in this confusing mess?

As a IT contractor, DEVOPS and cloud-native Java enterprise platform engineer, I would start migrating to Java 10 from yesterday. Especially, if the end result, such a final candidate release will be after September 2018. I expect the short hop of frustration migrating from Java 10 to Java 11. Most of the pain, will be migrating Java 8 code to the Java 10 and beyond.

There are advantages for migrating to Java 10 and beyond.

  • Java 10 compacts memory usage in the Java Virtual Machine. For example Compact strings take advantage of the fact that characters in many applications tend use only 8 bits in reality instead allocating 16 bits.
  • Migrating to Java 10 means you can generate your own modular JRE, which has a less of foot print in cloud-native provision.
    Of course, you get much better performance, because those clever hotspot engineers at Oracle and the wider OpenJDK project have improved optimisations around bytecode execution.
  • Your business is protected from security vulnerabilities
  • There are improvements Java Runtime that take advantage native machine code and CPU hardware
  • Compilation speeds are going to be faster
  • If you need graphics, then you get the latest improvements to JavaFX and Open JFX
  • Since Java 9, the garbage collector G1 is the new default compactor. G1 is designed for server runtime JRE, it can operate concurrently with applications threads like the CMS collector. It reduces GC pauses and is more predictable without sacrifices throughput performance.
  • And there is more stuff for example Java 9 added the beginnings of Ahead of Time compilation, which is an experimental feature and only available for Linux

That’s it for now.

Published on Java Code Geeks with permission by Peter Pilgrim, partner at our JCG program. See the original article here: Hot shot 003 – Thinking of Java 10 and beyond

Opinions expressed by Java Code Geeks contributors are their own.

Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments
Back to top button