Java 8 vs Java 11 – What are the Key Changes?

Updated 03/11/2022: Java 11 is no longer the most recent Long Term Support (LTS) Java release. Read our new article here: https://blog.idrsolutions.com/java-17-vs-java-11/

With Java 11 as the latest LTS release of Java, what is different between it and the previous LTS? This blog post is here to point out the key changes between the two versions.

Please note that these are not the only changes between the versions. If you choose to migrate to Java 11, we recommend thoroughly testing first.

New Features

First and foremost, what new features have been added in the 4 and a half years between the two versions?

1. Modularity: One of the biggest changes is the modularity introduced with Java 9. Modularity allows for you to split your applications into different modules, but also changes how java handles its API internally.

With a module-info file, you can manage access on what parts of your code is public facing. Without this file your code still compiles, it just gets placed into the unnamed module. The unnamed module behaves similarly to Java 8 compiled code.

You can find out more details on modularity with one of our earlier blog posts.

2. Version String Schema: Another change between the two versions is how the version strings are formatted. Versions will now be using a new schema of so<major>.<minor>.<security> that rather than something like 11u31, where the security patch is unknown, you can find out simply by looking at the last value.

3. Multi-jar releases: One of the features we tested out at the start of the year was the use of multi-jar releases. This feature provides a way for you to still code with the latest features of Java 11 while maintaining support and functionality for Java 8 clients. It’s certainly worth checking out.

4. Var keyword: The developer-friendly var keyword that came with Java 10 is another feature which helps to reduce the boilerplate coding. By only affecting local variables, the Type Inference stops you repeating the same text over and over again.

5. --releaseflag: Lastly there’s the ability to compile at for older platform versions with the new flag,--release this flag is a simple combination of,-source-target and allowing-bootclasspath you to compile at older versions. For example, --release 8is all you need to compile at a Java 8 level. (Please note that this works with compiling to Java 8+)

Deprecations

The next thing to compare the two versions on is the deprecations:

1. Due to the removal of support for Java browser plug-ins, the Applet API has been deprecated (but not yet removed).
2. To reduce the maintenance burden of the Garbage collection code base, the Concurrent Mark Sweep (CMS) Garbage Collector has been deprecated and will no longer be supported.
3. With the rapid pace that ECMAScript’s API changes, the amount of maintenance for the Nashorn JavaScript Engine have caused it to be deprecated.
4. With improvements to compression schemes in Java 9, Pack200 Tools and API have not been used since Java 8 and as such, they have been deprecated.
5. Due to an overlap with the Java EE Platform Specification, the Java EE module has been deprecated and removed.
6. Because it evolves independently of Java SE, the CORBA module has been deprecated and removed.

Other changes

Last but not least, a few things to keep in mind:

1. The default garbage collector has been changed to G1 – To reduce the pause times for most users the default garbage collector has been switched.
2. OpenJDK is now as close to Oracle JDK binaries as possible, after changing to a more frequent release schedule for Java 9 onwards. Due to this Oracle JDK, 11 and OpenJDK 11 are more interchangeable than OpenJDK 8 and Oracle JDK 8 are.

If you found this useful, you may also want to read our related articles, in which we look at Which JDK should I use now?, Using JavaFX with Java 11 or Higher

Our software libraries allow you to