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. 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?

6. Contracts & Services
Provider
module
Service
Registry
Consumer
module
Register
service
Lookup
service
Inject
service
Use an interface as contract

7. OSGi modularity demo

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

14. modules.xml
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);
}

23. JSR-376 linking
Runtime image
jdk.base
jdk.desktop
my.mod1
my.mod2
JVM

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. Comparing
Jigsaw & OSGi

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?

41. The future

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

47. @pbakker sdd
@Sander_Mak
Luminis Technologies
Thank you.
code @ bit.ly/carprov