It was announced a few days ago that JDK 9 is Feature Complete! Many of the "features" that made the cut are additions, but some are removals. This post looks at some of the items being removed from OpenJDK and/or Oracle's JDK with Java 9.
Endorsed-standard Override Mechanism and Extension Mechanism
Part of JEP 220 ("Modular Run-Time Images") is the removal of the Java Endorsed Standards Override Mechanism ("means whereby later versions of classes and interfaces that implement Endorsed Standards or Standalone Technologies may be incorporated into the Java Platform") and the removal of the Extension Mechanism for Support of Optional Packages ("allows the Java virtual machine (VM) to use the classes of the optional extension in much the same way as the VM uses classes in the Java Platform"). Upgradeable Modules are intended to replace the endorsed-standard override mechanism in JDK 9. Regardung the extension mechanism, JEP 220 states, "The extension mechanism was introduced in JDK 1.2, which was released in 1998, but in modern times we have seen little evidence of its use." Erik Costlow's post Planning safe removal of under-used 'endorsed extension' directories provides more background on these removals and how to detect if they will affect a particular Java application.
rt.jar and tools.jar
JEP 220 also removes the well-known and frequently-referenced JARs rt.jar and tools.jar. JEP 220 explains, "The class and resource files previously stored in lib/rt.jar, lib/tools.jar, lib/dt.jar, and various other internal jar files will now be stored in a more efficient format in implementation-specific files in the lib directory. The format of these files will not be specified and is subject to change without notice." Additional details on the removal of these JARs and anticipated effects of these removals can be found in Java 9 completely changes JDK directory layout and drops tools.jar, How Java 9 And Project Jigsaw May Break Your Code, and Prepare for JDK 9. No one argues that it was well advertised that these APIs were not intended for external use, but "some popular libraries make use of non-standard, unstable, and unsupported APIs that are internal implementation details of the JDK and were never intended for external use."
"Most" Internal APIs (But Not sun.misc.Unsafe!)
JEP 260 ("Encapsulate Most Internal APIs") was written to "make most of the JDK's internal APIs inaccessible by default [in JDK 9] but leave a few critical, widely-used internal APIs accessible, until supported replacements exist for all or most of their functionality." Mark Reinhold's message Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.) describes the motivation for this in detail. This approach was a compromise after the uproar over removing the internal (and infamous) API sun.misc.Unsafe. The JEP 260 documentation discusses in some detail which internal APIs will remain accessible in JDK 9 and explains that some will be deprecated in JDK 9 and removed altogether at some later point. The "critical internal APIs proposed to remain accessible in JDK 9" include sun.misc.Unsafe, sun.misc.Signal, and sun.misc.SignalHandler.
Java DB
In the post Deferring to Derby in JDK 9, Oracle's Don Smith writes, "Java DB is simply a re-branded distribution of the Apache Derby open source database. It contains the same binaries as Apache Derby. As of JDK 9, it is no longer being planned to include it in the 'db' directory of Oracle JDK downloads. Developers looking ahead to JDK 9 should plan to get and bundle Apache Derby independently for the same purpose." As of this writing, the Oracle Java DB page states, "Java DB is Oracle's supported distribution of the Apache Derby open source database. It supports standard ANSI/ISO SQL through the JDBC and Java EE APIs. Java DB is included in the JDK." This will no longer be the case as of JDK 9.
Garbage Collector Options Deprecated Since JDK 8
As documented in the "Removed" section of the OpenJDK page JDK 9 Outreach and in JEP 214, "rarely used" garbage collection options combinations deprecated in JDK 8 are now removed altogether (meaning that the inclusion of these combinations of options will prevent JVM from starting rather than simple presenting warning messages). Here are the combinations of garbage collection options to be removed:
| DefNew + CMS | -XX:-UseParNewGC -XX:+UseConcMarkSweepGC |
| ParNew + SerialOld | -XX:+UseParNewGC |
| ParNew + iCMS | -Xincgc |
| ParNew + iCMS | -XX:+CMSIncrementalMode -XX:+UseConcMarkSweepGC |
| DefNew + iCMS | -XX:+CMSIncrementalMode -XX:+UseConcMarkSweepGC -XX:-UseParNewGC |
| CMS foreground | -XX:+UseCMSCompactAtFullCollection |
| CMS foreground | -XX:+CMSFullGCsBeforeCompaction |
| CMS foreground | -XX:+UseCMSCollectionPassing |
jhat
JEP 241 is called "Remove the jhat Tool" and its concise "Summary" is, "Remove the antiquated jhat tool." The motivation to remove jhat is explained in JDK-8059039, "jhat was added in JDK 6, based upon the java.net HAT project. jhat is an experimental, unsupported, and out-of-date tool. Superior heap visualizers and analyzers have now been available for many years." Alternatives to jhat include Eclipse Memory Analyzer Tool (MAT) and VisualVM. This removal is also documented in the OpenJDK JDK 9 Outreach documentation and is mentioned in the article OpenJDK 9: Life Without HPROF and jhat.
Java Virtual Machine Tool Interface hprof Agent
JEP 240 removes the JVM TI hprof Agent from the JDK. The JDK 8 TechNotes on HPROF: A Heap/CPU Profiling Tool states (I've added the emphasis), "The Java 2 Platform Standard Edition (J2SE) has always provided a simple command line profiling tool called HPROF for heap and cpu profiling. HPROF is actually a JVM native agent library which is dynamically loaded through a command line option, at JVM startup, and becomes part of the JVM process." As stated in JDK-8046661 used to remove this, there are other alternatives available for generating "heap dumps in the hprof format" including jmap -dump and jcmd <pid> GC.heap_dump. This is also referenced on the JDK 9 Outreach page and is discussed in the article OpenJDK 9: Life Without HPROF and jhat.
VisualVM
Oracle's Aurelio Garcia-Ribeyro writes in the post Visual VM in JDK 9 and Beyond that "starting with JDK 9, Visual VM will not be included with Oracle JDK" and adds, "Developers who would like to use Visual VM with Oracle JDK 9 or later can get it from the Visual VM open source project site. This appears to be correlated with Oracle's earlier decision to donate NetBeans to Apache Software Foundation (VisualVM is based on the NetBeans Platform). One of the primary tools to use instead of the removed jhat tool and HPROF agent will also need to be downloaded separately for use with JDK 9.
AppleScript Engine
AppleScript engine code is removed with JDK 9 and this removal is documented in the "Removed" section of the OpenJDK page JDK 9 Outreach.
HTTP Proxying from RMI
HTTP proxying from RMI was deprecated with JDK 8 and is being removed from JDK 9. This is called out on the JDK 9 Outreach page.
Default Resolution of java.corba and EE Modules
The java.corba and other EE modules will still be available in JDK 9, but they will no longer be visible by default. The six modules "that will not be visible by default" are java.activation, java.annotations.common, java.corba [deprecated], java.transaction, java.xml.bind, and java.xml.ws. JEP 261 describes this in more detail and explains, "Modules that define Java EE APIs, or APIs primarily of interest to Java EE applications, are not resolved by default for code on the class path." It calls this change an "intentional, if painful, choice" intended "to avoid unnecessary conflicts with popular libraries that define types in some of the same packages" and "to make it easier for existing application servers to migrate to JDK 9.".
-source and -target Support for Java 1.5
The "Summary" of JEP 182 ("Policy for Retiring javac -source and -target Options") states, "To reduce the maintenance costs of javac, this JEP defines a policy for retiring old -source and -target options. In JDK 8, use of a source or target of 1.5 or earlier will be deprecated and in JDK 9, support for a source or target of 1.5 or earlier will be removed. In JDK 9 and going forward, javac will use a 'one + three back' policy of supported source and target options. Under this policy, javac will still be able to recognize and process class files of all previous JDKs, going back to version 45.3 class files generated by JDK 1.0.2, which first shipped in 1996."
Per the policy outlined in JEP 182, JDK 9 "remove[s] support for 1.5 and earlier source and target options" via JDK-8011044. Joe Darcy described this change when it was delivered, "The javac command no longer support -source or -target options below 6/1.6. However, older class files are still readable by javac. Source code for older release can be ported to the newer source level. To generate class files usable by older release, a javac from a previous release train can be used."
Other Removals
The "Removed" section of the OpenJDK JDK 9 Outreach page briefly references some of the items I discussed in this post and also references some items being removed from JDK 9 that I did not reference in this post:
- JEP 231 ("Remove Launch-Time JRE Version Selection"): "Remove the ability to request, at JRE launch time, a version of the JRE that is not the JRE being launched."
- JDK-8037739: "Remove API references to java.awt.peer and java.awt.dnd.peer packages in the JDK 9 timeframe"
- JDK-8029806: "Remove Packer/Unpacker addPropertyChangeListener and removePropertyListener methods"
- JDK-8029805: "Remove LogManager addPropertyChangeListener and removePropertyChangeListener methods"
- JDK-8029904: ""Remove com.sun.security.auth.callback.DialogCallbackHandler"
- JDK-7067728: "Remove stopThread RuntimePermission from the default java.policy"
- JDK-8134808: "Remove support for serialized applets from java.desktop"
Conclusion
Many of the items being removed from JDK 9 are being removed because of changes to the JDK to support modularity (JEP 200). Other items are being removed because there are better supported alternatives or because the products formerly included with the JDK are now expected to be downloaded separately.
