Download to read offline
![ClassLoader.getSystemResource() In JDK 9
● jrt:/[$MODULE[/$PATH]]
jrt:/java.base/java/lang/Class.class](https://image.slidesharecdn.com/kya2wzhfqcebs5jneqdr-signature-d4804e0e82e0753d47c4fc2b7f61f9df7964456ab3b881bee7183c3a09e0666c-poli-161204100758/75/Prepare-for-JDK-9-28-2048.jpg)
Uploaded byhaochenglee
Prepare for JDK 9
This document provides an overview of preparing for JDK 9, including changes to internal APIs, module system, and tools like jdeps. Key topics include encapsulation of internal APIs, the new version-string format, and enhancements such as JShell and HTTP/2 support. It emphasizes the importance of adapting code for compatibility with JDK 9's new features and structure.
More Related Content
Prepare for JDK 9
- 1. Prepare for JDK9 haocheng@KKTOWN
- 2. About me ● SeniorEngineer@KKTOWN ● Twitter: @haocheng ● Podcast: http://www.techtalk.tw/
- 3. Agenda How to preparefor JDK 9 No Project Jigsaw JShell HTTP/2 Support
- 4. Java Version Survey ●Java 8 ● Java 7 ● Java 6 ● Java 5 ● Java 1.4 ● … ╮(╯_╰)╭
- 5. Delayed Again... ● 2016/09 ●2017/03 ● 2017/07 ● ??? (ㆆᴗㆆ) http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-September/004887.html
- 6. Incompatible Changes inJDK9 ● Encapsulate most internal APIs ● Remove small number of Supported APIs ● Change binary structure of JDK/JRE ● New Version-string format ● JavaEE modules not resolved by default
- 7. API Classification ● Supported/PublicAPI ○ JCP standard: java.*, javax.* ○ JDK specific: com.sun.*, jdk.* ● Unsupported/JDK Internal API ○ sun.* ■ sun.misc.BASE64Encoder ■ sun.misc.Unsafe
- 8. General Compatibility Policies ●If an application uses only supported APIs and works on release N then it should work on N+1, even without recompilation ● Supported APIs can be removed but only with advanced notice
- 9.
- 10.
- 11. Categories of JDK-InternalAPIs ● Non-critical ○ No evidence of use outside of JDK or used only for convenience ● Critical ○ Functionality that would be difficult, if not impossible, to implement outside of the JDK
- 12. JEP 260: EncapsulateMost Internal APIs ● Encapsulate all non-critical internal APIs by default ● Encapsulate all critical internal APIs for which supported replacements exist in JDK 8 ● Do not encapsulate critical internal APIs ○ Deprecate them in JDK 9 ○ Plan to remove in JDK 10 ○ Provide a workaround via command-line flag
- 13. JEP 260 Proposal ●Propose as critical internal APIs ○ sun.misc.Unsafe -- low level access ○ sun.misc.{Signal,SignalHandler} -- signal handling ○ sun.reflect.Reflection::getCallerClass -- logging library ○ sun.reflect.ReflectionFactory -- serialization framework
- 14.
- 15. Prepare for JDK9 ●jdeps tool (from JDK 8) ● Maven JDeps plugin $ jdeps -jdkinternals app.jar
- 17. Workaround --add-exports java.base/sun.security.provider=ALL-UNNAMED --add-exports java.base/sun.security.pkcs=ALL-UNNAMED --add-exportsjava.base/sun.security.util=ALL-UNNAMED --add-exports java.base/sun.security.x509=ALL-UNNAMED
- 18. Using command line --add-exportsjava.base/sun.security.provider=ALL-UNNAMED source module package target module
- 19. Or with JARfile manifest Add-Exports: java.base/sun.security.provider
- 20. Enhanced Deprecation ● Revampthe @Deprecated annotation ● Strengthen the API lifecycle ● JEP 277
- 21. @Deprecated A program elementannotated @Deprecated is one that programmers are discouraged from using, typically because it is dangerous, or because a better alternative exists. Compilers warn when a deprecated program element is used or overridden in non-deprecated code.
- 22. Revamped @Deprecated ● forRemoval() ○true/false ● since() ○ version
- 23. Re-structured JRE directorylayout ● Accommodate module system ● Improve performance, security, and maintainability ● New URI Scheme - jrt ● JEP 220
- 24. JDK 8 RuntimeImage
- 25. JDK 9 RuntimeImage
- 26. JDK 9 RuntimeImage ● bin - all command-line launchers ● conf - config files for developers/users ● lib ○ run-time system's dynamically-linked native libraries ○ Other files are private implementation details ● Removed: rt.jar & tools.jar ○ Stored in more efficient format ○ Subject to change without notice
- 27. ClassLoader.getSystemResource() In JDK8 jar:file:/usr/local/jdk8/jre/lib/rt.jar!/java/lang/Class.class
- 28. ClassLoader.getSystemResource() In JDK9 ● jrt:/[$MODULE[/$PATH]] jrt:/java.base/java/lang/Class.class
- 29. Deprecations of InternalAPI ● Removed ○ java.util.logging.LogManager::addPropertyChangeListener ○ java.util.logging.LogManager::removePropertyChangeListener ○ java.util.jar.Pack200.Packer::addPropertyChangeListener ○ java.util.jar.Pack200.Packer::removePropertyChangeListener ○ java.util.jar.Pack200.Unpacker::addPropertyChangeListener ○ java.util.jar.Pack200.Unpacker::removePropertyChangeListener ● JSR 337: Java SE 8 Release Contents
- 30. Java EE modulesnot resolved by default java.activation -- JavaBeans Activation Framework java.annotations.common -- Subset of the Common Annotations java.corba -- CORBA java.transaction -- Subset of Java Transaction API java.xml.bind -- JAXB java.xml.ws -- JAX-WS JEP 261
- 31. New Version-String Format ●Old Version-String is difficult to understand ○ Java SE Development Kit 8u101 (1.8.0_101-b13) ○ Java SE Development Kit 8u102 ○ Critical Patch Updates vs. Patch Set Updates ● Impacts java -version and related properties ● JEP 223
- 32.
- 33. New Version-String SystemProperties
- 34. Multi-Release JAR Files ●Allow multiple, Java-release-specific versions of class files to coexist in a single archive ● Enable your application to build/run on older JDK ● JEP 238
- 35. Multi-Release JAR Files jarroot - A.class - B.class - C.class - D.class - META-INF - MANIFEST.MF → Multi-Release: true - versions - 9 - A.class - B.class
- 36. Compile for OlderPlatform Versions ● Compile Java programs to run on selected older versions of the platform ● JEP 247 ● JDK 8 ○ javac -source 7 -target 8 -bootclasspath:$JDK7 ... ● JDK 9 ○ javac --release 7 ...
- 37. Prepare for JDK9 ● Use jdeps to check usage of JDK-Internal APIs ● Check code may be affected by version change ● Check if your code have relied on runtime image layout or rt.jar/tools.jar ● Test the JDK 9 EA Builds
- 38. JShell ● REPL forJava! (FINALLY) ● No need to declare variable ● No need to write class ● Support auto-completion
- 41. HTTP/2 Client ● SupportHTTP/2 + WebSocket + HTTP/1.1 ● Support HTTPS/TLS ● Support asynchronous call ● Simple and concise API ○ HttpClient ○ HttpRequest ○ HttpResponse ○ WebSocket ● JEP 110
- 43.
- 44. References: Project Jigsaw Project JigsawTalks JDK 9 module summary JEP 220: Modular Run-Time Images JEP 260: Encapsulate Most Internal APIs JEP 261: Module System JEP 238: Multi-Release JAR Files JEP 247: Compile for Older Platform Versions JEP 277: Enhanced Deprecation java.corba and EE modules not resolved by default What is the difference between Java CPU and PSU Releases
Editor's Notes
- #31 JDK module summary: http://cr.openjdk.java.net/~mr/jigsaw/ea/module-summary.html
- #32 http://superuser.com/questions/1110066/what-is-the-difference-between-java-cpu-and-psu-releases-eg-jdk-se-8u101-and-jd Oracle strongly recommends that all Java SE users upgrade to the latest CPU release available for a release family. Most users should choose the CPU release. Users should only use the corresponding PSU release if they are being impacted by one of the additional bugs fixed in that version as noted in the release notes. The subsequent CPU release will contain all of the fixes from the current PSU. For this reason, organizations should test the current PSU in their environment in anticipation of these fixes being included in the next CPU.