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

Location confirmed for OSGi Exam in San Francisco - Jan 22, 2015

Happy New Year to everyone. We hope you had a good end to 2014 and are refreshed and raring to go for 2015.

For those of you in the Bay Area don't forget the OSGi Developer Certification - Foundation Level Exam on Thursday Jan 22 between 13.30 and 17.00. 

We are pleased to confirm that we have finalized the downtown San Francisco location of the exam and it is:

Rincon Center, 121 Spear Street
San Francisco
CA
94105





This is just a 5 minute walk from the Embarcadero BART station so we hope it will work well for everyone.

You can find out further details about the exam and topics that may be included on the OSGi website here.

To book a place please sign up here.

If you have any questions please email us.