java modularity: life after java 9
TRANSCRIPT
Contracts & Services
Provider module
Service Registry
Consumer module
Register service
Lookup service
Inject service
Use an interface as contract
History of JigSaw
JSR-277 Java Module System
2005 2006 2011 2014
JSR-294 Improved Modularity Support
Java 7: No JigSaw
Java 8: No JigSaw
JSR-376 Java Platform Module System
JSR-291 'OSGi 4.1'
Goals‣ Modularise the JDK and runtime ‣ Strong encapsulation - hide platform internals ‣ Reliable application composition ‣ Improved performance and security
Current status‣ JDK9 modularised ‣ JSR 376 requirements DRAFT 2 - no prototype yet
Goals‣ Modularise the JDK and runtime ‣ Strong encapsulation - hide platform internals ‣ Reliable application composition ‣ Improved performance and security
Current status‣ JDK9 modularised ‣ JSR 376 requirements DRAFT 2 - no prototype yet
Final
Yesterday
JSR-376 modules module myFirstModule @ 1.0.0 { exports com.public.api; requires myOtherModule @ 1.0; }
module-info.java
‣ Dependencies are transitively resolved on modulepath ‣ Versions: ordered, but not semantic ‣ Access control happens deep in VM
(IllegalAccessException)
JSR-376 modules module myFirstModule @ 1.0.0 { exports com.public.api; requires myOtherModule @ 1.0; }
module-info.java
‣ Dependencies are transitively resolved on modulepath ‣ Versions: ordered, but not semantic ‣ Access control happens deep in VM
(IllegalAccessException)
in Jar, or new jmod container
JSR-376 services module myApi @ 1.0.0 { exports com.api; }
module myConsumer @ 1.0.0 { requires myApi; requires service com.api.MyService; }
JSR-376 services module myApi @ 1.0.0 { exports com.api; }
‣ Services resolved and wired by modular runtime ‣ Use with 'enhanced' ServiceLoader API
module myConsumer @ 1.0.0 { requires myApi; requires service com.api.MyService; }
module myProvider @ 1.0.0 { requires myApi; provides service com.api.MyService with myProviders.MyServiceImpl; }
JSR-376 services module myApi @ 1.0.0 { exports com.api; }
‣ Services resolved and wired by modular runtime ‣ Use with 'enhanced' ServiceLoader API
module myConsumer @ 1.0.0 { requires myApi; requires service com.api.MyService; }
module myProvider @ 1.0.0 { requires myApi; provides service com.api.MyService with myProviders.MyServiceImpl; }
Iterable<App> apps = ServiceLoader.load(App.class);
for(App app: apps) { render(app); }
JSR-376 linking‣ Use a linking tool (jlink) to create a custom 'runtime
image' with only the modules you need ‣ Uses explicit dependencies from module-info.class ‣ Allows for whole-program optimization
Runtime image
jdk.base
jdk.desktop
my.mod1
my.mod2
JVM
Module vs package dependencies
‣ Module dependency: depend on a module, no matter what’s in it ‣ Package dependencies still exist in code (imports) ‣ What if a package moves to a different bundle?
‣ Package dependency: depend on a package, no matter where it comes from ‣ Better decoupling
Module vs package dependencies
class
package
module
imports
exports
exports imports
class
package
bundleexports
exports
Java 9 OSGi
imports
imports
Exported packages
‣ Has qualified exports ('permits') ‣ Exported packages only visible to pre-defined 'friend
modules' ‣ Necessary to split up JDK
‣ Multiple modules may export same package ‣ Can re-export packages from imported modules
JigSaw
Services
‣ Services are explicit in module metadata ‣ Service wiring statically verifiable?
JigSaw
OSGi‣ Services wired programmatically ‣ Service dynamics & bundle lifecycle ‣ Services can have properties, filters
‣ Java 9 might include a module index ‣ Maps from annotation to annotated
classes for direct lookup
Classpath scanning
Alternative: register a service, don't rely on classpath scanning
‣ Requiring multiple module versions is common
‣ Breaks in a flat class path
Module versions
MyModule
LoggingLib 2.0
LoggingLib 1.0
SomeLib
‣ JSR-376 draft spec states:
“It is not necessary to support more than one version of a module within a single configuration.”
Module versions
‣ Load/unload additional modules at runtime
‣ Alternate module versions in dynamic configurations
Java 9 dynamic configurations
Module versions
‣ Add, remove, update bundles at runtime ‣ Services are inherently dynamic
OSGi
Java 9‣ Dynamic configurations need to be
supported for Java EE ‣ Unclear how
jdeps carprov.music.jar carprov.music (carprov.music.jar)
-> carprov.dashboard.api carprov.dashboard.api.jar -> java.lang java.base -> java.lang.invoke java.base -> javafx.collections jfxrt.jar -> javafx.event jfxrt.jar -> javafx.geometry jfxrt.jar -> javafx.scene jfxrt.jar -> javafx.scene.effect jfxrt.jar -> javafx.scene.image jfxrt.jar -> javafx.scene.input jfxrt.jar -> javafx.scene.layout jfxrt.jar -> javafx.scene.paint jfxrt.jar -> org.osgi.framework org.osgi.core.jar
module-info.java module carprov.dashboard @ 1.0.0 { exports carprov.dashboard.api requires org.osgi.core @ 5.0 requires service carprov.dashboard.api.App }
module carprov.music @ 1.0.0 { requires carprov.dashboard @ 1.0 requires org.osgi.core @ 5.0 provides service carprov.dashboard.api.App with carprov.music.MusicApp }
‣ Modularity requires clean design ‣ Import / export declarations are step 1 to
modularity ‣ Services need to be a first class citizen ‣ Reloadable modules come with dynamics
‣ ... which brings some complexity
Modularity isn’t trivial
Is OSGi too complex?
The future - OSGi on top of Java 9?
Interoperation — It must be possible for another module system, such as OSGi, to locate Java modules and resolve them using its own resolver, except possibly for core system modules.
Not all JigSaw concepts map cleanly to OSGi
‣ A future OSGi could use the module definitions of Java 9
‣ Project Penrose: OSGi/JigSaw interop (looks inactive currently)
‣ Jars with module-info.class & OSGi metadata possible
The future - OSGi on top of Java 9?
‣ Use jdeps to audit your code ‣ Escape hatch: -XaddExports:java.base/sun.misc
‣ Java 9: a long way from being complete ‣ Services need more love than just
ServiceLoader (CDI integration?) ‣ Classpath/jars won't die ‣ Will it ever be enough?
The future - state of Java 9
‣ JSR-376 forces module-aware tooling ‣ Modularity throughout all
development phases ‣ Gradual migration possible (other
than with OSGi)
Java 9's promise
‣ JSR-376 forces module-aware tooling ‣ Modularity throughout all
development phases ‣ Gradual migration possible (other
than with OSGi)
Java 9's promise
Spotlight on modularity == good