When Will Java 11 Replace Java 8 as the Default Java?

The latest version of the Java Development Kit, Java 11, is out. Ever since JDK Beta made its debut back in 1995, there has been continuous development of the platform for this high-level, general-purpose programming language.

The release of Java 11 followed Java 10 only by 6 months. This is in line with the proposal made by Mark Reinhold, Chief Architect of the Java platform, back in 2017. He proposed to replace the two-year schedule with a twice-a-year release cycle.

At the moment, Java 8 and Java 11 are the LTS (long-term support) versions. The end of public updates for Java 8 is scheduled for January of 2019 for commercial use. For non-commercial use, the same is scheduled at an unspecified date in December of 2020.

What’s interesting with Java 11, aside from all the added, removed, and deprecated features, is that it won’t be supported by Oracle. In its place, the OpenJDK community will provide long-term support, most probably in the form of AdoptOpenJDK.

What About Other Java Releases?

With the release of Java 11, support for Java 10 ended. This is because it was a rapid release version, like Java 9, which contained support that has also been removed.

Though JDK versions prior to Java 8 are still supported by organizations on a commercial basis, it is highly recommended to uninstall pre-Java 8, especially from Windows computers. Before answering the question: “when will Java 11 replace Java 8 as the default version of Java?,” let us first get to know Java 11 better.

New in Java 11

Each release of Java introduces a number of new features. However, this time, it’s bigger and better. Java 11 adds a multitude of new features to the existing feature list. Here are some of the most important ones:

Additions

• 10 new scripts, including Adlam, Newa, Tangut, and Zanabazar Squar
• A scalable, low-latency garbage collector, ZGC or Z Garbage Collector, is added along with Epsilon GC, an experimental No-op Garbage Collector
• Accessible via JVMTI, a low-overhead heap profiling is now available
• Addition of a new default method toArray (IntFunction) to the java.util.Collection interface
• ChaCha20 and ChaCha20-Poly1305 ciphers are available. ChaCha20 is a new stream cipher meant to replace the old, and insecure as well, RC4 stream cipher
• Combines Unicode 9.0.0 and 10.0.0
• Enhanced SunEC provider, supporting 4 additional Brainpool curves
• Implementation of a new key agreement scheme using Curve25519 and Curve448
• Improved Java launcher to run a program supplied as a single file of Java source code
• Includes the implementation of the TLS 1.3
• Introduction of  jceks.key.serialFilter, a security property
• JVM now supports the arrangement of classes and interfaces into a nest, a brand new access-control context
• New command line flag, -XX:+UseDynamicNumberOfCompilerThreads. It is added to dynamically control compiler threads
• RSASSA-PSS signature algorithm support is added to the SunMSCAPI provider
• Standardized HTTP Client
• Support for the Kerberos 5 encryption types of aes128-cts-hmac-sha256-128 and aes256-cts-hmac-sha384-192
• Updated locale data based on the Unicode Consortium’s CLDR (Common Locale Data Registry)
• var, a reserved type name, is usable when declaring the formal parameters of a lambda expression

Removals

Not only has the latest iteration of the Java Development Kit introduced a plethora of features, but it also has axed some of its older features. Most of them have been deprecated in previous Java releases. Features and options that are no longer available in JDK 11 include:

• The  appletviewer tool. It was depreciated in JDK 9
• Bundled fonts. Hence, JDK 11 relies solely on fonts installed on the operating system
• com.sun.awt.AWTUtilities class, which received depreciation in JDK 10
• CORBA and Java EE modules
• JavaFX modules, now available as a separate set of modules
• Java Plugin and Java WebStart technologies. Java Control Panel, for configuring the deployment technologies, is removed along with the shared system JRE and the JRE Auto Update mechanism
• jdk.snmp module
• JMC (Java Mission Control). However, it is available as a separate downloadable module
• Specification for JVM monitoring and management through SNMP, JVM-MANAGEMENT-MIB.mib
• sun.misc.Unsafe.defineClass class. Its replacement is java.lang.invoke.MethodHandles.Lookup.defineClass
•  sun.nio.ch.disableSystemWideOverlappingFileLockCheck and  sun.locale.formatasdefault properties
• Support for images with alpha is no longer available to the javax.imageio JPEG plugin
•  Thread.destroy() and Thread.stop(Throwable) methods

Depreciations

With the release of every major version of the Java platform, there are some depreciations alongside inclusions and exclusions. JDK 11 deprecates:

• Command line arguments -XX:+UnlockCommericalFeatures and -XX:+LogCommercialFeatures
• jcmd commands: VM.check_commercial_features and VM.unlock_commercial_features
• Nashorn JavaScript engine, corresponding APIs, and jjs tool
• Pack200 API in java.util.jar and pack200 and unpack200 tools
• Stream-based GSSContext methods, including acceptSecContext, getMIC, initSecContext, unwrap, verifyMIC, and wrap
• ThreadPoolExecutor, the finalize method that shut down the thread pool does nothing
• VM option –XX:+AggressiveOpts

Check this for in-depth details about additions, removals, and deprecations made in the JDK 11.

So When Will Java 11 Replace Java 8 as The Default Java?

The simplest answer is: not anytime soon! We already discussed that some organizations, and individuals as well, still rely on pre-Java 8 versions for continuing their operations. This will be true for Java 8 also. Moreover, it is an LTS version that means it will outlast the rapid release versions.

Another argument that supports this idea is that Java 11 is relatively new. Therefore, it will take some time to gain traction. Most of the businesses that are already mushrooming with the deployment of Java 8 will continue reaping benefits from it.

Can’t decide which one to use for using Java 11? OpenJDK or Oracle JDK. Well, here’s a contrast between the two to help you make your selections.

OpenJDK Vs. Oracle JDK

Attempts for making OpenJDK and Oracle JDK binaries as similar as possible are in action. Nonetheless, there are still several dissimilarities between the two in the 11th major release of Java. Some of the most important ones are:

• APIs, like javafx and resource management, are not included in OpenJDK binaries but in Oracle JDK binaries
• OpenJDK allow the use of unsigned third-party crypto providers, whereas Oracle JDK requires that such providers be signed with an Oracle-provided certificate
• OpenJDK comes with only Java Development Kit while Oracle JDK additionally offers Java Runtime Environment
• OpenJDK is available as a compressed archive (tar.gz or .zip). On the contrary, Oracle JDK is available as installers (deb, msi, deb, etc.)
• OpenJDK is available under GPLv2wCP license while Oracle JDK is released under the OTN license
• Output for java -version is different in OpenJDK than in Oracle JDK
• The contents of \legal\java.desktop\freetype.md are different for both OpenJDK and Oracle JDK
• Usage logging is exclusive to Oracle JDK
• Using –XX:+UnlockCommercialFeatures flag will result in OpenJDK throwing an error and halting. On the contrary, using the same in Oracle JDK will print a warning but execution will continue
• While OpenJDK offers Alpine Linux, Oracle JDK offers Solaris

Hope this helps you make your JDK selections!

Start Learning Java today!

by  Vijay Singh

ORIGINAL