| Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. 3
| “plus ça change, plus c'est la même chose” – Jean-Baptiste Alphonse Karr (1808-1890) 4 Image Credit: "Alphonse Karr". Licensed under Public Domain via Commons - https://commons.wikimedia.org/wiki/File:Alphonse_Karr.jpg#/media/File:Alphonse_Karr.jpg
| JEP 260: Encapsulate most internal APIs • The vast majority of internal APIs are inaccessible by default in JDK 9 • A handful of critical, widely used internal APIs like sun.misc.Unsafe without good alternatives remain accessible by default in JDK 9 – until supported replacements exist for all or most of their functionality • Preparation: – jdeps tool can help identify programs that might be impacted • jdeps from JDK 9 EA is more up to date – Multi-Release JAR files (JEP 238) allow Java-release-specific versions of a class to coexist in a single JAR file – A command line flag would provide access to encapsulated APIs as a last resort 7
| JEP 223: New Version String Scheme • New version string is closer to Semantic-Versioning and drops some long kept baggage (e.g the “1.” in front, the use of “u” for updates) • Contents of Java version related system properties change as well • Preparation: – Test version string checking code • Common sources of surprise: GA version string is „9“ instead of „9.0.0“, or „1.9.0“ – Version string checking code targeting both JDK 9 and earlier versions will have to deal with both “old” and “new” version string formats 8 $MAJOR.$MINOR.$SECURITY
| New version-string format : Hypothetical Examples Release type Old format Long form Old format Short form New format Long form New format Short form Early Access 1.9.0-ea-b19 9-ea -> 9-ea+19 9-ea Major 1.9.0-b100 9 -> 9+100 9 CPU 1.9.0_5-b20 9u5 -> 9.0.1+20 9.0.1 Minor 1.9.0_20-b62 9u20 -> 9.1.2+62 9.1.2 9
| JEP 220: Modular Run-Time Images • Internal structure of the installed JDK has changed – Due to usage of modules instead of JAR files • Directory structures and filenames inside the JDK installation have changed • Preparation: – Check if your code assumes a specific layout of the JDK installation – Use new jrt URI scheme to access modules, classes, and resources stored in a run- time image • jrt:/java.base/java/lang/Class.class • jrt:/jdk.crypto.ec • Use jrt-fs.jar with JDK 8 10 Removed: rt.jar and tools.jar
| Remove most sun.misc.* and sun.reflect.* APIs • In order to keep critical APIs without a replacement accessible by default sun.misc and sun.reflect will not be hidden and a few APIs kept “public” – sun.misc.Unsafe – sun.misc.{Signal,SignalHandler} – sun.reflect.Reflection::getCallerClass – sun.reflect.ReflectionFactory • All other APIs in these packages (e.g. sun.misc.Base64) will be removed 12 Except for a few called out in JEP 260
| General rule: Look out for unrecognized VM options • Launching JRE with unrecognized VM options fails • Using deprecated options in JDK 8 triggers warning messages $ java -XX:MaxPermSize=1G -version Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize; support was removed in 8.0 • Previously deprecated options, removed in JDK 9, will fail to start – Perm generation was removed in JDK 8 (JEP 122) 14
| JEP 231: Remove Launch-Time JRE Version Selection • Multiple JRE (mJRE), introduced in JDK 5, allowed specifying what JRE version, or range of versions, should be used to launch an application • The version(s) could be specified in a manifest entry in the application jar or through a command line parameter • In JDK 9 version(s) selected through the manifest will be ignored (with a warning), version(s) selected through the command line will err and exit 15
| Endorsed Std Override and Extension mechanism, deprecated in 8u40, dropped in 9 • Extension mechanism (also called Optional Packages) made APIs available to any application running on the platform • Endorsed Standards was used for updating certain classes and interfaces of the runtime without updating the whole JRE • JDK 9 fails if anything is placed on ${java.home}/lib/ext and ${java.home}/lib/endorsed or if you use java.ext.dirs system property • Preparation: – JDK 8u40 introduced -XX:+CheckEndorsedAndExtDirs to print a message if you are using the extension or standard mechanisms – Use upgradable modules or put jars on the classpath instead 16 JDK-8060206
| JEP 271: Unified GC Logging • GC logs are in a different format – Parsers might need to be reworked • Most common flags are deprecated and remapped -XX:+PrintGC becomes -Xlog:gc -XX:+PrintGCDetails becomes -Xlog:gc* -Xloggc:<filename> becomes -Xlog:gc:<filename> 19 Re-implemented GC logging with the new JVM logging framework from JEP 158
| G1 is the new default garbage collector • Parallel GC was the default up to JDK 8 on most platforms – Still there but no longer the default – Can select Parallel GC via command flags 21 JEP 248: Make G1 the Default Garbage Collector
| What can you do to prepare? • Check code for usages of JDK-internal APIs with jdeps • If you develop tools then check code for a dependency on rt.jar or tools.jar or the runtime-image layout • Check code that might be sensitive to the version change • Check code for uses of underscore as an identifier • Check code for uses of unrecognized VM options such as -XX:MaxPermSize • Test the JDK 9 EA builds and Project Jigsaw EA builds https://wiki.openjdk.java.net/display/Adoption/JDK+9+Outreach 24
| Safe Harbor Statement The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. Oracle Confidential – Internal 31
rigadevday
holman
jacobian
phodgson
dotmariusz
jnunemaker
samanthasiow
searls
lara
brettharned
deanohume
shpigford
maggiecrowley
