Brief description about Java modularity including OSGi and Jigsaw.
Nowadays the word "modularity" has been searched a lot in Google and several blog posts have been written about it. Specially with the #Jigsaw subject that Oracle's guys have been spreading in different conferences .
Here I try to summarise the idea in the Java environment mentioning what for me are the main implementations of java modularity : OSGi and Jigsaw.
2. 1 What is NOT modularity ?
2 So, what is modularity then ?
3 Why use modularity ?
4 Implementations of modularity
5 OSGi
6 Jigsaw
7 Jigsaw vs Osgi
8 References
4. compile time runtime
What is NOT modularity ?
Monolithic system
• One piece
• No subcomponents
• Tight coupling
• No independent existence
• Growing functionality and
interdependence
6. What is Modularity ?
• Module :
• Every single deployable unit
• Design technique that emphasises separating the functionality into
modules that are :
• Independent
• Interchangeable
• One functionality
9. Java Modularity - Why ?
• Cons
• Adds tracking complexity
• Needs more good code practices
• Forces us to consider more flexibility
• Think about collateral effects
• May add architecture complexity
13. Java Modularity - OSGi
Started in 1998
Different implementations : Equinox, Felix, Knoplerfish,
Karaf, Fabric8, Netbinox
Current specs OSGi Alliance release 6.0
Every bundle ( module )
Its own class loader
Its own lifecycle
Service discovery
Dynamic loading (lazy, eager activation)
Meta information included in META-INF file
Used in : Eclipse IDE, Netbeans IDE, Glassfish, WildFly, Adobe AEM (
Sling )
15. Java Modularity - Jigsaw
Started in 2014
In Early Access now, or final release in JDK 9 in 2017
Explicit declaration of
Importing modules
Exporting packages
Meta info in module-info.java file
Module names must be unique
Not includes versioning
Introduce a new artifact format : JMOD
16. Java Modularity - Jigsaw
Modules dependencies in Jigsaw
com.foo.app
com.foo.app.api
com.foo.app.report
java.sql
java.logging
java.base
can not read
depends
java.xml
reads
com.foo.other
depends
reads
depends &
publishes
17. Java Modularity - Jigsaw
Module specification :
module com.foo.bar { // module definition
requires com.foo.baz; // module needed
exports com.foo.bar.alpha; // package published
exports com.foo.bar.beta to // package published ONLY
com.foo.client, // to these modules
com.foo.reporter;
provides com.foo.api.MyInterface with // publishing a service
com.foo.impl.MyImpl;
uses com.foo.api.YourInterface; // consuming a service
requires public com.slf4j; // module needed AND
// made readable to everyone
// who requires this module com.foo.bar
}
19. Java Modularity - Jigsaw
Main differences
Jigsaw OSGi
Module dependency Java package dependency
Version agnostic ( only 1 allowed ) Version capable ( lots of versions
loaded at the same time )
No lifecycle management Lifecycle management
Export constraints No export constraints
Static modularity at deployment Dynamic modularity at deploy +
runtime
hi, thank you for coming
in this presentation I will try to show
some basic concepts about modularity,
and specially in Java
well, first of all I would want to thank you all the people that have helped to refine this presentation with their comments, thank you.
this is the agenda I will try to cover during the talk, from the definition of concepts to detail of some implementations and finally comparing those implementations
if we want to talk about java modularity
first we should start defining what is modularity
but instead I will start defining what is NOT modularity
because we have to recognise the differences
*so, the contrary of a modular application would be a monolithic application
*having the image of a monolith as a single giant block of stone or metal
*these are some characteristics that a monolithic system can have :
—made in only one deployable piece
—it doesn't have subcomponents that we can deliver separately
—if we have different parts in our app but we still have tight coupling between those parts we will have a monolith also
—another characteristic of a monolithic system could be that its parts don't have existence apart from the other parts
—and finally we can end in a monolithic system if during the time of development we have grown the functionality and the interdependence between the parts at the same time
then now ,
we know what is NOT modularity,
so lets see what could be one description of what is modularity
* first, I will describe what a module could be, and in this case I consider a module as every deployable unit that your compilation creates
and here we have a description of what modularity could be :
a design technique where we invest effort in creating different models that are :
—- independent because they can run separately
—- interchángebol because they work using contracts and we can replace them with other modules
—- and with limited functionality for every module to ease the separation of concerns
as I said this is the ideal situation, maybe reality could be different
now we come to
what are the benefits of using modularity and maybe also
what are the drawbacks of using it
so some of the pros that we can find using modularity are :
* that it helps to louse coupling because we separate the logical parts of the system into modules and for that we work using contracts
* also it can help optimising development because teams can work “separately” without waiting one team for another to finish their code
* also it may ease the escalation and evolution of the application as
we can evolute a single module without “affecting” the rest of the system
* also it forces us to reuse modules due to the single functionality principle
* and finally we can test every module more easily without having a lot of parts interconnected
but also we can find some drawbacks that we should consider if we adopt this pattern:
* one of them is that it adds more tracking complexity because instead of tracking one deployable unit you have to deal with several , specially for versions
* also it needs us to be more accurate with our code practices to avoid repeating code, to keep independence
* in some cases we also have to consider more flexibility because we will have different typologies of module consumers and also restrict the collateral effects that they can cause to the system
* and finally we can end with more architecture complexity because of the protocols we need to interconnect the modules, runtimes where deploy them and the formats to define the modules
so now that we know what is and what is not modularity we are going to see some of the implementation we can find out there
first we can see 2 implementations that are famous, everyone for different reasons.
* SOA as an architectural design that converts your system into a lot of web services with different elements that provide interconection, security, balance, etc
*also we have micro services, that nowadays is very trendy and it claims to be an evolution and radical improvement of SOA where you split your app into modules that have nothing in common with the other micro services not sharing even the persistence layer nor the coding language
*then we have the two implementations that motivated this presentation
—OSGi as an implementation considering the compile and runtime modularity, having module lifecycle control, service discovery and injection, restriction of the visibility for the public packages, and also the ability to manage different version of the same package at the same time
—and finally Jigsaw as a way to modularise your app ( and the JRE ) creating smaller modules that you can combine at the delivery time
it was created initially to reduce the JRE delivering only the needed libraries and its now expected to come to life the next year
I will try to briefly describe the last two implementations, OSGi and Jigsaw
And I will start with OSGi giving a fast introduction to it just to describe a bit deeper Jigsaw and see the main differences
people searches in google are always curious, don't you think ?
well, OSGi started 18 years ago and is present in some of the most used apps among developers
there are some implementations but basically are Felix and Equinox and the rest can run one of them and add some enterprise features
actually the last release is the 6.0 released in 2014
every bundle in the system has its own class loader and we an control the lifecycle of every bundle independently
it has a service registry where any service can be registered and later any managed class can query that registry and inject the required service
also we can configure those osgi components to be loaded and activated at start time or at the moment they are needed by other modules
the information about exporting and importing packages is included inside the meta-ind file, although all of us use bnd maven plugin to generate that meta info on the compilation time.
now we move to see what is jigsaw apart from a movie character and a game….
its an oracle project related to the JDK that now is in early access and will be final released next year
it defines explicit declaration for importing modules and exporting packages , including constraining the destination module
uses the module-info.java file to define the module
does not cover the module versioning as we’ve seen with OSGi
and introduces a new artefact call JMOD that includes .jar, config files, and documentation
also it has a default module for non defined modules called unnamed
and it does not consider the lifecycle of the modules as it does OSGi
here is just a simple case of dependencies introducing the concept of modules
in this example we have our com.foo.app module with 2 packages inside, an api package exported and a report package not exported
it depends on java.sql and is capable to read the exported packages of it, but its not capable to read anything inside java.logging , there is no transitive readability and to solve that we can explicitly define a dependency as public…the case with java.xml
in this example we can see a declaration file for a module with the elements to describe the dependencies : requires, exports, exports to, provides, uses and requires public
so, now we have seen some characteristics of jigsaw and osgi and as a fast comparative we will see a table with the main facts
while jigsaw have dependencies at a module level, in osgi that dependencies are at a package level no matter the module where they are.
also jigsaw is version agnostic and for that we can not have 2 different versions of the same module running together
jigsaw also is not intended to control the lifecycle of any module
with jigsaw we find that we can constraint with who a module is sharing a package
and finally jigsaw is intended to generate a modularity at deployment time having several tiny parts of the code, but in OSGi we have that modularity in the runtime also thanks to the container
well, I would like to end this presentation showing some references that may help those of you who want to know more about this topic.
these are some of the people that post often about OSGi and Jigsaw.
Peter as principal member of the OSGi Alliance and Neil as an OSGi expert and maintainer of the BND Tools. Also we have Paul Bakker as a constant blogger about OSGi and creator of Amdatu, a list of tools to create modular apps with OSGi. We also have JeanBaptiste as the PMC of the Apache Karaf project, an OSGi container with more features. And finally we have Mark Reinhold as the Chief Architect of the Java platform at Oracle.
here i’ve put some links for every main subject including the Devoxx Talk by Mark Reinhold about jigsaw that I was proud to assist last November.
and finally here you can see some books that could help when considering modularity as a design for your apps.
I’ve included also 2 sci-fi books about generated realities… just because I like them a lot.
well, thats all from my side ( as we say every morning )
hope you have enjoyed the presentation… and if you have easy questions, please go shoot me.