This document discusses modularity in Java applications and platforms. It covers OSGi, a popular modular system for Java that allows bundles to be installed and updated dynamically. It also discusses Project Jigsaw, which aims to add built-in modularity to the Java platform starting in JDK 9 by defining Java modules. Project Penrose explores interoperability between OSGi and Jigsaw modular systems.
5. Modularity 101
Standard Java libraries are modules - Hibernate,
log4j and any library you can basically think of …
Build systems like Maven provide transparent
management of modules
6. Modularity 101
Benefits of modularization:
– smaller modules are typically tested easier than a
monolithic application
– allows for easier evolution of the system - modules
evolve independently
7. Modularity 101
Benefits of modularization:
– development of the system can be split easier
between teams/developers
– increased maintainability of separate modules
8. Modularity 101
The dependency mechanism used by the JDK
introduces a number of problems that modular
systems aim to solve:
– The "JAR hell" problem caused by shortcomings of the
classloading process
9. Modularity 101
The dependency mechanism used by the JDK
introduces a number of problems that modular
systems aim to solve:
– The lack of dynamicity in managing dependent
modules
– The lack of loose coupling between modules
10. Modularity 101
Module systems aim to solve the mentioned
problems and typically provide:
• module management
• module deployment
• versioning
• dependency management
• module repositories
• configuration management
12. Modularity on top of the platform:
OSGi
OSGi (Open Service Gateway iniatiave) provides a
specification for module systems implemented in
Java
It is introduced as JSR 8 and JSR 291 to the Java
platform
13. Modularity on top of the platform:
OSGi
Q: So what is an OSGi runtime ?
14. Modularity on top of the platform:
OSGi
Q: So what is an OSGi runtime ?
A: An OSGi runtime (module system) makes use of the Java
classloading mechanism in order to implement a container for
modular units (bundles) and is based on the OSGi spec - a series
of standards by the OSGi Alliance. Many application servers are
implemented using OSGi as a basis - it is also used in systems
from a diversity of areas
15. Modularity on top of the platform:
OSGi
Q: So what is an OSGi runtime ?
A: An OSGi bundle is a just a JAR file that contains source code,
bundle metadata and resources. A bundle may provide various
services and components to the OSGi runtime. An OSGi runtime
allows for bundles to be installed, started, stopped, updated and
uninstalled without requiring a reboot
16. Modularity on top of the platform:
OSGi
Q: So what is an OSGi runtime ?
A: The OSGi Core spec defines a layered architecture that
determines what is supported by the runtime – each layer
defines a particular functionality supported by the runtime and
the bundles
OSGi logical units:
bundles
services
services registry
life-cycle
modules
security
execution environment
OSGi logical layers:
17. Modularity on top of the platform:
OSGi
Q: So what is an OSGi runtime ?
A: Bundles may export packages for use by other bundles or
import packages exported by other bundles - this dependency
mechanism is referred to as wire protocol and is provided by the
Module layer of OSGi.
18. Modularity on top of the platform:
OSGi
Q: So what is an OSGi runtime ?
A: Bundles may publish services to the runtime and use already
published services from the runtime – this dependency
mechanism is provided by the Service layer of OSGI.
19. Modularity on top of the platform:
OSGi
Q: So what is an OSGi runtime ?
A: The MANIFEST.MF file of the bundle’s JAR file describes the
metadata of the bundle
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Sample
Bundle-SymbolicName: com.sample
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: com.java2days.seminar.demo.Activator
Bundle-Vendor: java2days
Require-Bundle: org.java.jigsaw.core,
org.java.jigsaw.extensions
Bundle-RequiredExecutionEnvironment: JavaSE-1.7
Service-Component: OSGI-INF/service.xml
Import-Package: com.java2days.seminar.jigsaw.shared;version="1.0.0“
Export-Package: com.java2days.seminar.demo.utils
20. Modularity on top of the platform:
OSGi
Q: So what is an OSGi runtime ?
A: The runtime may implement extensions based on the OSGi
Compendium spec that extends the OSGi Core spec. These could
be: remote services
log service
HTTP service
device access service
configuration admin
metatype service
preferences service
user admin
wire admin
DMT admin service
IO connector service
provisioning service
UPnP device service
configuration admin
declarative services
event admin service
deployment admin
XML parser service
monitoring service
others
24. Modularity of the platform:
Jigsaw
When speaking of modularity we should also
consider the entire runtime (rt.jar) and the JDK core
libraries …
… and built-in support for improved "OSGi-like"
modules in the Java platform
26. Modularity of the platform:
Jigsaw
JDK 8 compact profiles provide smaller versions …
(javac -profile <profile_name> or
make profiles for an OpenJDK build)
compact 1 compact 2 compact 3
27. Modularity of the platform:
Jigsaw
The aim of project Jigsaw is to provide a module
system for the Java platform
Although deferred to JDK 9 some additional effort
such as Compact Profiles and removed/ deprecated
inter-library dependencies have been introduced in
JDK8 as an intermediate solution
28. Modularity of the platform:
Jigsaw
Modularization of the Java platform is a significant
change that impacts the entire ecosystem - may
even break existing projects
29. Modularity of the platform:
Jigsaw
Draft 3 of Jigsaw requirements states that
application using only standard APIs must remain
compatible
Draft 3 of Jigsaw requirements also mentions that
some JDK-specific APIs must remain compatible but
no concrete JDK APIs are listed yet
30. Modularity of the platform:
Jigsaw
Q: So what is exactly project Jigsaw ?
31. Modularity of the platform:
Jigsaw
Q: So what is exactly project Jigsaw ?
A: Jigsaw will provide the basis for a Java Module System JSR.
Currently work on Jigsaw is being done for:
JEP 200 - define JDK modules (in a modules.xml file in the JDK repo)
JEP 201 - reorganize JDK sources into modules and modify JDK build
JEP 220 - restructure JRE/JDK images to accommodate modules
32. Modularity of the platform:
Jigsaw
Q: So what is exactly project Jigsaw ?
A: Structure of JDK sources as defined by JEP 201:
old
src/{share,$OS}/{classes,native}/$PACKAGE/*.{java,c,h,cpp,hpp}
new
src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java
native/include/*.{h,hpp}
$LIBRARY/*.{c,cpp}
conf/*
33. Modularity of the platform:
Jigsaw
Q: So what is exactly project Jigsaw ?
A: In the early exploratory phase of project Jigsaw there was a
proof-of-concept implementation with JDK8 early-access builds
(now dropped).
34. Modularity of the platform:
Jigsaw
Q: So what was exactly the exploratory phase of Jigsaw ?
A: Jigsaw POC provided a modularized version of JDK along with
additional tools and language support for creating Jigsaw
modules. JDK8 early-access builds provided two types of JDK:
JDK modules image - all components are preinstalled as
modules
JDK base image + jmod packages - base JDK installation along
with additional Jigsaw modules of the JDK that can be
installed on-demand using the jmod tool
36. Modularity of the platform:
Jigsaw
Q: What is a Jigsaw module ?
A: A collection of Java classes, native libraries and other
resources along with metadata that provides name and version
of the module and dependencies on other modules
37. Modularity of the platform:
Jigsaw
Q: What is a Jigsaw module ?
A: Jigsaw resolves modules during build and installation.
Jigsaw has no dynamics, no module lifecycle. The module system
assumes the existence of a foundational module named
java.base
38. Modularity of the platform:
Jigsaw
Q: What is a Jigsaw module in terms of the exploratory phase ?
A: Module can use ("require") other modules and additionally
specify version or version ranges for the module dependency -
modules are loaded with different module classloaders
module org.bgjug.A @ 1.0 {
requires org.bgjug.B @ [2.0, 3.0);
}
module org.bgjug.A {
requires org.bgjug.B @ >= 1.0;
requires org.bgjug.C @ < 2.0;
}
39. Modularity of the platform:
Jigsaw
Q: What is a Jigsaw module in terms of the exploratory phase ?
A: Module versions are compared using a similar approach as the
one used for Debian package versions … The intent is to be able
to package a module as an OS-specific package (not applicable
for Windows/Mac OS)
40. Modularity of the platform:
Jigsaw
Q: What is a Jigsaw module in terms of the exploratory phase ?
A: Modules can also "require" optional modules - meaning that
compilation succeeds even if the required module is missing
module org.bgjug.A {
requires optional jdk-corba@8-ea;
}
41. Modularity of the platform:
Jigsaw
Q: What is a Jigsaw module in terms of the exploratory phase ?
A: Modules can also "require" local modules - meaning that the
local module is a kind of a "mixin" - it is loaded in the same
classloader as the requiring module
module org.bgjug.A @ 1.0 {
requires local org.bgjug.B @ [2.0, 3.0);
42. Modularity of the platform:
Jigsaw
Q: What is a Jigsaw module in terms of the exploratory phase ?
A: A module may export packages and classes
module org.bgjug.A @ 1.0 {
requires org.bgjug.B @ [2.0, 3.0);
exports org.bgjug.A.seminar.Sample;
exports org.bgjug.A.seminar.samples.*;
}
43. Modularity of the platform:
Jigsaw
Q: What is a Jigsaw module in terms of the exploratory phase ?
A: Modules can explicitly specify which other modules can
"require" them
module org.bgjug.A@ 2.0 {
exports org.bgjug.A.seminar;
permits org.bgjug.B;
}
44. Modularity of the platform:
Jigsaw
Q: What is a Jigsaw module in terms of the exploratory phase ?
A: Modules can logically provide other module names (aliases):
module com.bgjug.A @ 1.0 {
provides com.bgjug.First @ 2.0;
}
45. Modularity of the platform:
Jigsaw
Q: What is a Jigsaw module in terms of the exploratory phase ?
A: Modules can have a single entry point
module org.bgjug.A @ 1.0 {
permits org.bgjug.B;
class org.bgjug.A.Main;
}
the main() method org.bgjug.A.Main is called when invoking:
java -m org.bgjug.A
46. Modularity of the platform:
Jigsaw
Q: What is a Jigsaw module in terms of the exploratory phase ?
A: Modules can define multiple views
module org.bgjug.A {
exports org.bgjug.A.seminar;
view org.bgjug.internal.view {
permits org.bgjug.B
}
}
the main() method org.bgjug.A.Main is called when invoking:
java -m org.bgjug.A
47. Modularity of the platform:
Jigsaw
Q: What is a Jigsaw module in terms of the exploratory phase ?
A: A module can declare that it provides a service
module org.bgjug.A {
provides service org.bgjug.A.external.TestService with
org.bgjug.A.external.TestServiceImpl;
}
48. Modularity of the platform:
Jigsaw
Q: What is a Jigsaw module in terms of the exploratory phase ?
A: A module can require a service
module org.bgjug.B {
requires service org.bgjug.A.external.TestService
}
49. Modularity of the platform:
Jigsaw
Q: What is a Jigsaw module in terms of the exploratory phase ?
A: A service can also be required optionally
module org.bgjug.B {
requires optional service org.bgjug.A.TestService;
}
50. Modularity of the platform:
Jigsaw
Q: So why not adopt OSGi (at least the module layer) for
modularization of the Java platform ?
51. Modularity of the platform:
Jigsaw
Q: So why not adopt OSGi (at least the module layer) for
modularization of the Java platform ?
A: As chief architect of the Java platform Mark Reinhold states:
The OSGI module layer is not operative at compile time - it
addresses modularity only during packaging, deployment and
execution. It is also strictly build on top of the platform so it
cannot be used to modularize it.
52. Modularity of the platform:
Jigsaw
Q: So why not adopt OSGi (at least the module layer) for
modularization of the Java platform ?
A: However - according to Peter Kriens (former technical director
at the OSGi Alliance and one of the key drivers behind the OSGi
spec) Jigsaw is not typically needed an will introduce burden to
the platform and modules can be introduced much easier:
The only thing we need to add to the existing system is
versioning information on the package and record this version in
the class file
55. OSGi and Jigsaw interoperability:
Penrose
When speaking of JDK modules we should consider
interoperability with existing module systems such
as OSGi
The purpose of project Penrose is to explore
interoperability between OSGi and Jigsaw
56. OSGi and Jigsaw interoperability:
Penrose
Penrose is still in early stage of development …
Current work on project Penrose is deprecated due
to the dropped proof-of-concept version of Jigsaw …
57. OSGi and Jigsaw interoperability:
Penrose
Penrose goals:
– ensuring OSGi frameworks run unmodified in a
Jigsaw-enabled runtime
– create modules/bundles that have both OSGi and
Jigsaw metadata in them
– Jigsaw metadata can be extended with OSGi concepts
– extend OSGi to read Jigsaw metadata
58. OSGi and Jigsaw interoperability:
Penrose
Penrose goals:
– mapping Jigsaw metadata to OSGi metadata
– resolve Jigsaw modules in an OSGi runtime
– enhance OSGi to use Jigsaw APIs
– more cross delegation between the two systems …
64. References
Modularity - what is it ?
http://www.infoq.com/articles/modular-java-what-
is-it/
Java modularity - why ?
http://java.dzone.com/articles/java-modularity-
2-why
Java JAR hell problem
http://en.wikipedia.org/wiki/Java_Classloader#JA
R_hell
66. References
Java Module System Requirements
http://openjdk.java.net/projects/jigsaw/doc/draf
t-java-module-system-requirements-12
Project Jigsaw: The Big Picture
http://cr.openjdk.java.net/~mr/jigsaw/notes/jigs
aw-big-picture-01
Java 8 Modules Jigsaw and OSGi
http://www.slideshare.net/mfrancis/java-8-
modules-jigsaw-and-osgi-neil-bartlett
67. References
Project Jigsaw: Late for the train
http://mreinhold.org/blog/late-for-the-train-qa
Unbearable lightness of Jigsaw
http://blog.osgi.org/2011/05/unbearable-lightness-
of-jigsaw.html
Netbeans discussion on Jigsaw
http://wiki.netbeans.org/Jigsaw
68. References
Java Modularity - OSGi and Project Jigsaw
http://techdistrict.kirkk.com/2009/06/12/java-modularity-
osgi-and-project-jigsaw/
The Modular Java Platform & Project Jigsaw
http://www.jfokus.se/jfokus14/preso/Jigsaw.pdf
JAX 2013: A Project Jigsaw primer
http://jaxenter.com/a-project-jigsaw-primer-
50029.html
69. References
JavaOne 2013: The Modular Java Platform and Project
Jigsaw
http://parleys.com/play/52549d02e4b0a43ac12
124be/about
OpenJDK Penrose JavaOne 2012
http://www.slideshare.net/bosschaert/open-jdk-penrose-
javaone-2012
Editor's Notes
Some people argue that Java libraries are not modules since they do not provide encapsulation (such as classes and packages).
Evolution of modules in the default classloading mechanism supported by the Java platform may cause the so called "JAR hell" problem when conflicting versions of the same library are present on the classpath or required by different libraries. In order to evolve libraries in a compatible way using the default classloading mechanism on must design libraries with backward/forward compatibility in mind.
Evolution of modules in the default classloading mechanism supported by the Java platform may cause the so called "JAR hell" problem when conflicting versions of the same library are present on the classpath or required by different libraries. In order to evolve libraries in a compatible way using the default classloading mechanism on must design libraries with backward/forward compatibility in mind.
multiple packages with the same name can be defined in different modules in that manner (and they are merged when modules are loaded)
the optional modules may be explicitly required to "permit" the requiring module in the future
multiple packages with the same name can be defined in different modules in that manner (and they are merged when modules are loaded)
the optional modules may be explicitly required to "permit" the requiring module in the future
multiple packages with the same name can be defined in different modules in that manner (and they are merged when modules are loaded)
the optional modules may be explicitly required to "permit" the requiring module in the future
multiple packages with the same name can be defined in different modules in that manner (and they are merged when modules are loaded)
the optional modules may be explicitly required to "permit" the requiring module in the future
multiple packages with the same name can be defined in different modules in that manner (and they are merged when modules are loaded)
the optional modules may be explicitly required to "permit" the requiring module in the future
multiple packages with the same name can be defined in different modules in that manner (and they are merged when modules are loaded)
the optional modules may be explicitly required to "permit" the requiring module in the future
multiple packages with the same name can be defined in different modules in that manner (and they are merged when modules are loaded)
the optional modules may be explicitly required to "permit" the requiring module in the future
The module can use an enhanced version of java.util.ServiceLoader to load the service
The module can use an enhanced version of java.util.ServiceLoader to load the service
The only benefit in Jigsaw according to Peter Kriens:
The only reason I can think of is that is easier for the module system providers to program. In the Jigsaw model traversing the dependencies is as easy as taking the module name + version, combining it with a repository URL, doing some string juggling and using the result as a URL to your module.