Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Java modularity: life after Java 9

3,837 views

Published on

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.

Published in: Technology
  • Be the first to comment

Java modularity: life after Java 9

  1. 1. Java Modularity: life after Java 9 @pbakker sdd @Sander_Mak Luminis Technologies
  2. 2. Today's journey Modularity matters Java 9 modularity JigSaw & OSGi The Future
  3. 3. Modularity matters Modularity is the ultimate agile tool
  4. 4. Good fences make good neighbours Hide your internals! Service contract Module
  5. 5. Contracts & Services MyInterface i = new MyImpl(); How to use code that you can’t access?
  6. 6. Contracts & Services Provider module Service Registry Consumer module Register service Lookup service Inject service Use an interface as contract
  7. 7. OSGi modularity demo
  8. 8. We don't have inside info Java 9: JigSaw, JSR-376
  9. 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. 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. 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. 12. They modularised the JDK without the module system? So you're telling me...
  13. 13. JEP 200: The Modular JDK
  14. 14. modules.xml JEP 200: The Modular JDK
  15. 15. JEP 200: The Modular JDK
  16. 16. JEP 200: The Modular JDK rt.jar & tools.jar gone Faster startup, lower footprint
  17. 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. 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. 19. JSR-376 services module myApi @ 1.0.0 { exports com.api; }
  20. 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. 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. 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); }
  23. 23. JSR-376 linking Runtime image jdk.base jdk.desktop my.mod1 my.mod2 JVM
  24. 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
  25. 25. Comparing Jigsaw & OSGi
  26. 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. 27. Module vs package dependencies class package module imports exports exports imports class package bundle exports exports Java 9 OSGi imports imports
  28. 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. 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. 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. 31. ‣ Requiring multiple module versions is common ‣ Breaks in a flat class path Module versions MyModule LoggingLib 2.0 LoggingLib 1.0 SomeLib
  32. 32. ‣ OSGi supports this with version ranges Import-Package: org.slf4j;version=“[1,2)” Module versions
  33. 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. 34. ‣ Load/unload additional modules at runtime ‣ Alternate module versions in dynamic configurations Java 9 dynamic configurations Module versions
  35. 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. 36. How would the OSGi demo be structured in Java 9/JigSaw?
  37. 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. 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. 39. ... is OSGi too complex? So that looks simple enough ...
  40. 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?
  41. 41. The future
  42. 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. 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. 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. 45. ‣ JSR-376 forces module-aware tooling ‣ Modularity throughout all development phases ‣ Gradual migration possible (other than with OSGi) Java 9's promise
  46. 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
  47. 47. @pbakker sdd @Sander_Mak Luminis Technologies Thank you. code @ bit.ly/carprov

×