Neil Bartlett asked me on Twitter a few days ago why the Eclipse Foundation was supporting the JSR for SE8, given that this JSR is “anti-OSGi”. That is a very good question.
I believe that Neil and others are basing their “anti-OSGi” read of the JSR based on Section 2.1’s description of modularity. “OSGi already does this” being the operative phrase. Of course, OSGi already does this stuff and could easily be the solution for the set of described requirements. However, I also believe that if you read the section purely from the perspective of the status quo which exists today for the JDK, all of the statements there are perfectly valid. The point made in Section 2.5 illustrates this further: “Existing [modularity] frameworks and tools support these tasks today, but standardization in the Java SE Platform would promote interoperability and benefit developers, users, and vendors.”
But the statement in the JSR which ultimately drew our support is in Section 3 (emphasis mine):
In the case of the proposed Java Platform Module System JSR, it is understood that there is already a significant investment within the Java community in applications and frameworks built using the module layer of the OSGi Service Platform. The extent to which the Java Platform Module System should adopt, interoperate with, or otherwise accommodate OSGi will be a topic for that JSR’s Expert Group and the Java SE 8 Expert Group to discuss and decide.
The bottom line is that this JSR (well actually the still-to-be-established JSR focused on modularity) represents the beginning of a conversation about the shape of modularity in the base Java platform. This conversation is going to take something on the order of one or two years to complete. We are supporting this JSR because it is the forum for that discussion. But if the end result is “anti-OSGi”, I’ve already made it clear that we will be voting against it. And although no one else has publically committed to a position, I think we will be in good company in doing so.
I should also be clear on what I mean by anti-OSGi. I haven’t spent a ton of time thinking about this, but at the moment my perspective is that the bottom line is the existing OSGi ecosystem must be able to continue operating on SE8 without any interruption. Further, OSGi cannot be disadvantaged by platform modularity in terms of performance or scalability. But I have heard enough comments from very competent Java developers who are unhappy with OSGi that I don’t believe that in its current form it is perfection personified. So perhaps there will be options along the lines revisions to OSGi specs, an inter-operability story or some other solution beyond the scope of my imagination or technical abilities. So “anti” does not equal “use OSGi in its current form or else” in my view.
I am not so naive as to think that this is going to be easy. Mark Reinhold and others at Oracle have made it pretty clear that OSGi in its current form is not the solution that matches their vision for platform modularity. To change this is going to require persuasion on both the technical and ecosystem/business benefits of OSGi. I use the word “persuasion” very consciously because I believe that the name calling and negative emotion which have been part of the modularity debates (on both sides) over the past couple of years have not, in my view, been helpful. We (the OSGi) community have one last kick at this can. This is it.
