Java Modularity

Before JavaOne, there were clearly changes in the air with respect to JSR 277 Modules for Java and JSR 294 Superpackages. The announcement of Glassfish to support OSGi and the project Fuji (an ESB/JBI implementation based on OSGi) represent a significant mind-shift at Sun. We also saw Stanley Ho's interoperability paper on the JSR 277 mailing list. I therefore was happily surprised when the JSR 277 Java Modularity spec leads, Alex Buckley and Stanley Ho, when they asked me if I still wanted to join JSR 277.

This question posed a dilemma for me. Was I still interested? Two years ago when JSR 277 started I was rejected and I made a big fuzz about this, which obviously puts a moral burden on me now. Also, the changes around JSR 294 Superpackages definitely inclined me to join. JSR 294 was now folded back in JSR 277 and its course had changed 180 degrees. Instead of an overly redundant poorly thought out model Alex had kicked the bucket under the superpackages draft and proposed the much simpler concept of an access modifier called module. Though this idea had not been worked out in detail, it clearly was much, much, more feasible. Modules setup this way could be very usable in the OSGi world. My technical me would love to work on this aspect.

However, JSR 277 now consists of two good (Repository and Language modules) and one bad part (JAM). Just before JavaOne 2008 Stanley had published a brief OSGi interoperability document. This document was not only very thin on details, it also referred in many places to an invisible Early Draft #2 (EDR2). I asked the EG members BJ Hargrave and Richard Hall if they had seen this EDR2, but it was unknown to them as well. I had recently complained about the lack of discussions on the JSR 277 mailing list, so it seems that work had been going on stealthily.

During the JSR 277 presentations Alex and Stanley it became clear to me that a lot of work had happened behind the scenes; Without any communications on the mailing lists. For somebody in the audience it was absolutely not clear that almost everything that was said was never discussed in the EG. How could I participate in an EG if the only option would be to approve work done at Sun behind the curtains? How much change can there be if the unpublished EDR2 is presented at JavaOne as the stable result for JSR 277? Should I join an EG where most of the work was already done? How many fundamental changes can you achieve in this situation?

I wish it was differently. Bryan Atsatt did a lot of work to convince Sun to open up, and it worked better than one could have expected. So, there is a lot of moral pressure on me to compromise and accept. As several people said: "Sun will not give up their JAMs, so get over it." Now, it is in my nature to compromise; I prefer working together on technical details instead of fighting. However, I just turned 50 years old and I can recall too many painful events where I compromised against my technical instinct. Years later the forces behind the compromise were forgotten and the inferior technical design remained with my name attached to it. I really do not like that and this seems one of those cases.

So why do I not like JAMs? Well, who needs them? Do they provide something that OSGi not already provides? Alex and Stanley stressed the "fact" that JAMs are "deterministic" and "simple", the Siren's song of simplistic solutions. Only when you do not fully understand the problem is JAM an attractive solution. The truth is, JAM creates unnecessary complexity, the worst of all.

There is only one argument that makes sense for a special module layer for the VM: The boot classes. Obviously during the boot phase a full-blown OSGi framework is not feasible because OSGi is written in Java. However, JAM will have exactly the same problems loading java.lang.Object because the environment to run the framework is not loaded yet. How do you process annotations without having the Class class loaded? Write an annotation layer in C? I will not even go into initialization and custom module binding support. Clearly, a special solution is required to modularize the core language packages. This problem was also faced by Apache Harmony. They also did not want to support a full blown OSGi framework in their VM, but they did understand the importance of existing standards. Apache Harmony modularized the bootpath classes and provides them as OSGi bundles using the standardized metadata. Because headers are in the manifest and easy to parse, no complex redundancy is required as with JAM's annotation support. Using the same metadata makes a seamless transition possible from booting all the way to running one of the many application servers defined on top of OSGi. For management systems it is ideal if they only have to worry about a single format.

We are now at a crucial point in time. Though I'd love to participate in the discussions about modules in the Java language and the repositories, I cannot become responsible for a module system in Java that is creating this complexity for no rational reason. I do hope Sun will take this last step as well, and drop JAM in favor of the much simpler approach of using the OSGi metadata throughout the system. In the last months we have gotten so far! Please?

Peter Kriens

P.S. Did you register at the Community Event yet? There are only 190 places and I think they will be filled up. After Sun's embrace of OSGi, a lot more people got interested. You surely do not want to miss it. Last week we finalized the program it looks surprisingly strong.

P.P.S. Do you regularly read this blog? Do you know you can become an OSGi supporter? This free of charge and it helps us make it more clear to people that you support OSGi, sometimes numbers help, becoming a supporter does help. Of course if you can afford it, we'd love even better to have you as a full member or adopter. Take a look at the conditions. Appreciated!