Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Java modularity: life after Java 9

•
•
S
Sander Mak (@Sander_Mak)

With modularity coming to the core Java platform in Java 9, are all our modularity needs fulfilled, or does it still make sense to use something like OSGi? In this talk you will learn how Jigsaw helps modularity, and in what cases it might fall short. Java 9 will provide a module-system, called Jigsaw. Besides modularising the JDK itself, Java developers can build more modular applications with Jigsaw. Modularity and Java go back way longer, though. OSGi, the de facto standard for modularity in Java has been around since 2000. Adoption is increasing in recent years. A modular architecture has many advantages, such as increased decoupling resulting in more flexibility. In that sense, native support for Java modularity is very welcome. The big question now is: does Java 9 provide everything you need to build truly modular applications? Since Java 9 needs to maintain backwards compatibility, some compromises need to be made while enforcing module boundaries. This talk discusses what you really need to build modular applications. We'll investigate which requirements are met (or not) by both module systems. You'll see that both Jigsaw and OSGi provided pieces of the modularity puzzle. Also, you'll learn whether having an additional modular runtime such as OSGi on top of Java 9 still makes sense.

1 of 47
Java Modularity: life after Java 9 @pbakker sdd @Sander_Mak Luminis Technologies
Today's journey Modularity matters Java 9 modularity JigSaw & OSGi The Future
Modularity matters Modularity is the ultimate agile tool
Good fences make good neighbours Hide your internals! Service contract Module
Contracts & Services MyInterface i = new MyImpl(); How to use code that you can’t access?
Contracts & Services Provider module Service Registry Consumer module Register service Lookup service Inject service Use an interface as contract
OSGi modularity demo
We don't have inside info Java 9: JigSaw, JSR-376
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
They modularised the JDK without the module system? So you're telling me...
JEP 200: The Modular JDK
modules.xml JEP 200: The Modular JDK
JEP 200: The Modular JDK
JEP 200: The Modular JDK rt.jar & tools.jar gone Faster startup, lower footprint
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; }
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 Runtime image jdk.base jdk.desktop my.mod1 my.mod2 JVM
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
Comparing Jigsaw & OSGi
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 bundle exports 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
‣ OSGi supports this with version ranges Import-Package: org.slf4j;version=“[1,2)” Module versions
‣ 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
How would the OSGi demo be structured in Java 9/JigSaw?
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 }
... is OSGi too complex? So that looks simple enough ...
‣ 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
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
@pbakker sdd @Sander_Mak Luminis Technologies Thank you. code @ bit.ly/carprov

More Related Content

Java modularity: life after Java 9

  • 1. Java Modularity: life after Java 9 @pbakker sdd @Sander_Mak Luminis Technologies
  • 2. Today's journey Modularity matters Java 9 modularity JigSaw & OSGi The Future
  • 3. Modularity matters Modularity is the ultimate agile tool
  • 4. Good fences make good neighbours Hide your internals! Service contract Module
  • 5. Contracts & Services MyInterface i = new MyImpl(); How to use code that you can’t access?
  • 8. We don't have inside info Java 9: JigSaw, JSR-376
  • 9. 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'
  • 10. 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
  • 11. 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
  • 12. They modularised the JDK without the module system? So you're telling me...
  • 13. JEP 200: The Modular JDK
  • 15. JEP 200: The Modular JDK
  • 16. JEP 200: The Modular JDK rt.jar & tools.jar gone Faster startup, lower footprint
  • 17. 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)
  • 18. 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
  • 19. JSR-376 services module myApi @ 1.0.0 { exports com.api; }
  • 20. JSR-376 services module myApi @ 1.0.0 { exports com.api; } module myConsumer @ 1.0.0 { requires myApi; requires service com.api.MyService; }
  • 21. 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; }
  • 22. 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); }
  • 24. 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
  • 26. 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
  • 27. Module vs package dependencies class package module imports exports exports imports class package bundle exports exports Java 9 OSGi imports imports
  • 28. 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
  • 29. 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
  • 30. ‣ 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
  • 31. ‣ Requiring multiple module versions is common ‣ Breaks in a flat class path Module versions MyModule LoggingLib 2.0 LoggingLib 1.0 SomeLib
  • 32. ‣ OSGi supports this with version ranges Import-Package: org.slf4j;version=“[1,2)” Module versions
  • 33. ‣ JSR-376 draft spec states: “It is not necessary to support more than one version of a module within a single configuration.” Module versions
  • 34. ‣ Load/unload additional modules at runtime ‣ Alternate module versions in dynamic configurations Java 9 dynamic configurations Module versions
  • 35. ‣ Add, remove, update bundles at runtime ‣ Services are inherently dynamic OSGi Java 9 ‣ Dynamic configurations need to be supported for Java EE ‣ Unclear how
  • 36. How would the OSGi demo be structured in Java 9/JigSaw?
  • 37. 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
  • 38. 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 }
  • 39. ... is OSGi too complex? So that looks simple enough ...
  • 40. ‣ 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?
  • 42. 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
  • 43. ‣ 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?
  • 44. ‣ 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
  • 45. ‣ JSR-376 forces module-aware tooling ‣ Modularity throughout all development phases ‣ Gradual migration possible (other than with OSGi) Java 9's promise
  • 46. ‣ 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