Java modularization

Editor's Notes

• #2: 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.
• #3: 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
• #4: 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
• #5: *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
• #6: then now , we know what is NOT modularity, so lets see what could be one description of what is modularity
• #7: * 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
• #8: now we come to what are the benefits of using modularity and maybe also what are the drawbacks of using it
• #9: 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
• #10: 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
• #11: 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
• #12: 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
• #13: 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 ?
• #14: 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.
• #15: now we move to see what is jigsaw apart from a movie character and a game….
• #16: 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
• #17: 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
• #18: 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
• #19: 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
• #20: 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
• #21: 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.
• #22: 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.
• #23: 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.
• #24: 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.
• #25: 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.