Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Java 8 Vote

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.

Written by Mike Milinkovich

October 14, 2010 at 5:16 pm

Posted in Open Source

10 Responses

Subscribe to comments with RSS.

  1. I understand your concerns around OSGi, yet wouldn’t the Java SE 8 JSR Expert Group be the natural forum in which to address this issue? In that case I’d think you’d want to vote in favor of initiating the JSR while reserving the right to vote against approving it later on if sufficient accomodation is not made.

    Mark

    October 14, 2010 at 6:03 pm

  2. Mark (as in Mark Reinhold I assume?),

    Yes, I agree that to have this resolved, we actually need to _create_ the JSR. My comments are directed to the approval votes that happen as the JSR does its work.

    Mike Milinkovich

    October 14, 2010 at 6:19 pm

  3. Jigsaw & JSR-294 are lots of things, including the very big effort of breaking internal API implementation dependencies that would prevent any kind of module system to work. And I suppose that Sun/Oracle have already been designing new APIs with more care for modularization. So it seems to me that even as currently planned, JDK 8 is already reasonably OSGi-friendly, even if it doesn’t go the full length of shipping the JDK as a collection of OSGi modules (the ideal world for the OSGi community).

    Now I’m very curious: we already have a significant experience with Apache Harmony; how well this experience has worked? (I honestly don’t know, never played much with either Harmony or OSGi.) Can you point to some study (no cheap blogs please, just serious stuff like published research papers) that explore Harmony’s modularization, discussing its effectiveness and overheads? I suppose there are some costs, because the Android platform didn’t keep the OSGi piece of Harmony, so maybe the tradeoff is good for EE apps only? What about SE apps – remember that Oracle is not doing some massive investment to resuscitate Java for desktop and RIA apps, so any microkernel (including Jigsaw) will face really tight constraints for increased VM loading-time / footprint, especially for simple apps?

    If the OSGi community can show this kind of data (and it’s positive data), that should serve as very strong argument for your goals. Nothing speaks louder that “Been There, Done That – AND we have objective evidence that our stuff works well”.

    Osvaldo Pinali

    October 18, 2010 at 9:01 am

  4. Hi Osvaldo,

    I agree that some of the effort that has gone into Jigsaw is beneficial even for OSGi, but Jigsaw proposes to go a lot further and as a result is not particularly “OSGi-friendly” as you put it.

    Remember, we are not necessarily asking for JDK8 to ship with an OSGi Framework. We are asking it NOT to ship with a poorly conceived, incompatible module system. However, even if JDK8 does ship with Jigsaw then I can live with that, so long as Jigsaw is not promoted as a reasonable module system for application developers to use.

    Even then(!) it would not be a complete disaster so long as JSR294 did a proper job of defining interoperability between Jigsaw and OSGi, e.g. a subset of shared metadata. Unfortunately that was not where JSR294 was headed, at least when it was active about 2 years ago. So we will end up with the following:

    * Java developers will be forced to pick which module system to support in the their libraries and applications, OR…
    * Developers wishing to support both Jigsaw and OSGi will need to maintain two separate sets of metadata (i.e. dependencies, versioning info etc) for both module systems.
    * They will have to build and test separately for both Jigsaw and OSGi
    * They will have to offer two separate download artifacts for each module

    So much for “write once run anywhere”. This is why Mike says that modularity is not a greenfield problem! It’s simply irresponsible to attempt to define a new solution in this space without giving consideration to the established standard.

    As for your call for data… it’s a chicken and egg problem. The data probably doesn’t exist for Harmony because Harmony has never really been used (sadly Android doesn’t count). But consider this: OSGi has been thoroughly proven in pretty much every area of the Java ecosystem except for the JRE itself… and that’s only because it was never tried. Why not try OSGi *first* to see if it can also work as a JRE modularisation technology, rather than rushing ahead with a solution that has such painful consequences for the Java community?

    Neil Bartlett

    October 18, 2010 at 10:20 am

  5. @Neil – Nice summary, thanks. To be clear, my main focus is compatibility and migration. It would be fine with me, for example, if Jigsaw was a strict subset of OSGi that played nicely with the bundles on top. I am _not_ of the opinion that Jigsaw must be == OSGi. Your summed this up perfectly with: “It’s simply irresponsible to attempt to define a new solution in this space without giving consideration to the established standard.” That’s what I meant to say🙂

    @Osvaldo, Neil’s response was actually better written than I could have, so I will leave it at that🙂

    Mike Milinkovich

    October 18, 2010 at 10:34 am

  6. @Neil, @Mike: Yes, good points from Neil. I consider OSGi very successful in products that i use like Eclipse and IBM WebSphere, so this is already some good evidence even if we don’t have a modularized JDK that’s proven in the trenches. But I wonder if some synthetic study could be performed, e.g. the folks at Apache could measure very precisely their overheads – for JVM boot-time, heap footprint, common classloading operations – for a reasonable set of applications: e.g. a small applet; a complex RIA app (I’ll gladly take Pivot while JavaFX is in the limbo); some mid-sized Eclipse RCP desktop app; a small WAR in a tight Java EE 6 Web Profile container; a large multi-EAR app in a big honky Full Java EE 6 container. Without this kind of data, the claim of “thoroughly proven” is incomplete at beast – the functionality is thoroughly demonstrated, but the performance aspects is not demonstrated at all. And I’m afraid that OSGi’s experience so far is very biased towards monster-sized applications like IDEs and app servers. The same overheads that are lost in the noise of apps that take half minute to boot and require PermGen tuning, may be very important in ones that should start instantly and run without ever expanding HotSpot Client’s default minimum 16Mb heap size.

    Osvaldo Pinali

    October 18, 2010 at 11:26 am

  7. Osvaldo, yes that kind of data would be very useful. Of course it take some effort to produce, so some company would need to sponsor the work.

    Subjectively I believe that OSGi applications start much faster and continue to run faster, because of the vastly reduced class spaces that must be searched each time a class is loaded. Of course it’s still possible for an OSGi developer to do stupid things that negate this benefit, but the potential is there.

    By the way, OSGi is very definitely not “biased towards monster-sized applications”… ProSyst built a compliant R4.2 implementation[1] on an ARM9 CPU running at 156 MHz and 8 MB RAM🙂

    [1] http://www.prosyst.com/index.php/de/html/news/details/18/smallest-OSGi/

    Neil Bartlett

    October 18, 2010 at 12:08 pm

  8. Cannot care less about the compatibility of the upcoming Java modularity system with OSGi – as latter is nearly unusable – as each developer using Eclipse plugins may confirm.

    Oleksandr

    October 30, 2010 at 9:49 am

  9. Glassfish and Netbeans (both Oracle/Sun sponsored project) now both support OSGI. I would suspect this means Oracle/Sun is not completely opposed to working with OSGI.

    Eric

    November 7, 2010 at 8:08 am

  10. @Oleksandr – Thank you for your constructive and insightful comment.

    @Eric – I agree. I think it will be interesting to watch this process as it evolves over the next year or so.

    Mike Milinkovich

    November 7, 2010 at 10:03 am


Comments are closed.

%d bloggers like this: