Thursday, January 8, 2015

Java Modularity Revisited

There is a new JSR for Java modularity: JSR 376 and it is already approved by the Executive Committee. Not sure where to start, but I would love to participate in this group because the approach seems to be much more attractive this time around. Reading the short description I understand that this time packages are not ignored, but they actually are the units of export. This means that OSGi and JSR 376 will share the same basic concepts. Even more positive, the JSR clearly states that it will be made compatible with OSGi. All in all an excellent start.

That said, why write a blog when you're all happy?

The key concern is that there is currently no OSGi expert in the EG. As stated, I'd love to participate. There are a number of issues that I think will require some attention to not gratuitously create hardships for the 'sophisticated applications' (words from the JSR, not mine!)  that will use OSGi on top of JSR 376.

First there is the rather simple problem (but oh so contentious) of versioning. With OSGi and bnd we have quite deep knowledge of semantic versioning as it is used in a Java world. What we learned is that interface/contract based programming with multiple implementations creates some subtleties around semantic versioning that are not present in language like Javascript, Ruby, etc. I would really appreciate a chance to present these lessons to the EG. We might solve the biggest pain the OSGi currently has with the JVM: packages that have no version, if we can solve this problem I will not ask for anything else! (Well, for now.)

Second, the dependency model. The prevalent dependency model in software is transitive identity dependency, an archetypical example is maven. It is simple but it also creates humongous graphs. Though Maven does not download the Internet, people download the internet because it is so easy to do. This is exactly the problem we had in Object Oriented technology and interfaces gave us the tool to break the transitivity. The OSGi model provides an elegant solution in the same vein as interfaces did for objects. I am not sure if this model should be pushed completely in the VM but it would be worthwhile to have a discussion around the differences and what the consequences for the OSGi compatibility are.

Last but and I guess also least: the Service Loader. The Service Loader in the Java Platform provides a way for modules to locate classes by their interface name. This is a crucial service in a module oriented system, it allows the discovery of available implementations. However, one could ask if (ab)using class loaders for discovery is a brilliant idea or if it is a hack that looks acceptable because we're so used to class loading hacks? The drawbacks of class loading hacks for extensions are that objects are created without context, often requiring statics and singletons to communicate. There are better solutions and I think it would be great if we could address service discovery in a better, more Java oriented, way. And I do believe this a crucial part of a module system; when you put a fence around your territory you better think about the gates.

So where do I sign up?

Peter Kriens



  2. Would love to see you on the jcp.

  3. Today I saw this in OTN news letter

    describing the state of JSR 376 and its design.

    As I've eagerly re-designed our system based on OSGi (R3 at the time) and tracking it since, I cant say I'm neutral in this discussion, but I think it would be a BIG time miss, waste of time and energy if EG does not consult OSGi on their strategies and approaches.

    I think the winning strategy would be to design and implement Jigsaw the way that it would complement OSGi. What I see now is just a common root, or not even that, just a common problem that EG is trying to solve again, taking a different approach, and I can assure them they will invent some wheels on their way just to find that OSGi has already done that, even better. The term "sophisticated applications" used in JSR 376 text to address redundancy of LC and DS is just a hint for that.

    For the benefit of all Java community, I think Jigsaw and OSGi must come into common terms before Jigsaw's development passes the stage where it cant change direction.