based on multiple talks in JavaOne 2015 and Devoxx BE 2015. This presentation is focused on features that are under active development, and as such, a lot can change before the final release.
the construction, maintainability, deployment and upgrade of large scale applications Enabling performance improvements Coming to you, March 2017 (postponed on Tuesday)
260) • Remove the JRE • Changing the binary structure of the JDK • Removed endorsed standards override and extension mechanisms • Removed bootclasspath • New version-string format • No more ‘_’ variables!
• sun.reflect.* • com.sun.image.* • sun.security.* • sun.net.* • Non-critical ◦ Only used internally ◦ Used for convenience • Critical ◦ Difficult to implement outside the JDK
APIs with replacements in 8 • Do not encapsulate critical APIs ◦ Deprecate in 9 ◦ Plan to remove in 10 • sun.misc.Unsafe • sun.misc.Signal • sun.misc.SignalHandler • sun.misc.Cleaner • sun.reflect.Reflection:: getCallerClass • sun.reflect.ReflectionFactory
APIs Check for code that relies on the JDK version number format Check for usages of underscore as an identifier Test your code with the early access builds
only be discovered at runtime. NoClassDefFoundError • Weak Encapsulation Across Packages ◦ Across package boundaries there is only one visibility: public ◦ class loader folds all loaded packages into one big ball of mud ▪ “jar file is a filesystem on a stick” - Mark Reinhold (lead Jigsaw Oracle developer)
compact profiles but are still cluttered ◦ large runtime image footprint (not ready for IoT and server containers) • Startup Performance ◦ class loading executes a linear scan of all JARs on the class path
modules • Reliable Configuration ◦ module/classes dependency graph available at any time (even runtime) • Strong Encapsulation ◦ A class that is private to a module should be private in exactly the same way that a private field is private to a class. In other words, module boundaries should determine not just the visibility of classes and interfaces but also their accessibility.
◦ strong encapsulation of module internal API ◦ critical code is now effectively hidden ◦ maintenance easier as a module’s public API can more easily be kept small. • Improved Performance ◦ optimization techniques can be more effective when it is known that a class can refer only to classes in a few other specific components rather than to any class loaded at run time • Scalable Platform ◦ cherry pick the functionality needed and create their own JDK ◦ important for small devices as well as for containers
name (with some dark wizardry) Simply move the non-modular JARs from the classpath to the modulepath Exports all packages Requires all modules on the modulepath
jackson.databind org. fenixedu.bar.gamma.Gamma Exception in thread "main" java.lang.reflect. InaccessibleObjectException: Unable to make member of class org.fenixedu.bar.gamma.Gamma accessible: module jackson.databind does not read <unnamed module @b8623654>
to the ‘Unnamed Module’ Reads all other modules in the application Exports all its packages Real modules are not allowed to explicitly depend on the unnamed module Read-node may be added in runtime via reflection