Yesterday I described the reasons why I think the Eclipse Foundation should vote in favour of the Java 7 JSR when it is proposed. We are no where near as positive about the Java 8 JSR.
The reason is modularity. We are just not comfortable that the direction of the Java 8 team will do an adequate job of bridging the divide between the OSGi world and whatever modularity model is decided upon for the platform. Which potentially means that Java 8 may ship in late 2012 (actually I predict early-to-mid-2013) with a modularity model which is orthogonal to, and incompatible with OSGi. In our opinion, that would be a disaster for the Java platform and the Java ecosystem.
Let’s recap just a few of the reasons why OSGi is important to both Java and Eclipse:
- OSGi forms the basis of the Eclipse plug-in model used by millions of Java developers. The Eclipse Equinox and Eclipse Gemini projects provide the reference implementations of quite a few of the OSGi RFC’s.
- OSGi is used by many of the Enterprise Service Bus (ESB) implementations out there.
- OSGi is used by almost all of the major Java EE application server implementations, including oddly enough Oracle’s WebLogic and Glassfish products.
I am not saying that OSGi is a panacea. There are lots of people out there who will happily tell you about all of the reasons why it is imperfect. For example, despite the fact that its roots are in embedded, it objectively has been a failure in the Java ME space. My point is that it is deeply ingrained in the Java ecosystem and in the architectures of many of the most successful Java products out there. I cannot imagine a scenario where ignoring or trying to replace it in a major Java platform release two and a half years from now can be anything other than a train wreck.
I would be awfully happy to be wrong, but my perception is that the Java 8 JSR is looking at modularity as a greenfield project where they need to arrive some sort of perfect solution, with no historical constraints. We, on the other hand, believe that: (a) there is an incumbent technology that must be accommodated and (b) the problem we collectively face is not software but social engineering. In the best interest of the Java community, some sort of compromise is going to be required.
The JCP is setup to mediate these types of technology decisions. The potential disagreement around Java 8 JSR is a technical issue, not a contract issue as is Java 7 JSR. Unless we see sufficient accommodation for OSGi in the Java 8 JSR we will be voting No.
