The Data Grid JSR Backlash and why you should support the JCP reforms

The recent backlash against Red Hat's data grid JSR proposal sparked an interest as I know the JCP is going under reform right now.

For those of you who have missed the debates, here's some background reading for you:

• http://bit.ly/gDrtP3,
• http://bit.ly/eeOWWF
• http://bit.ly/hKiNg1

So, here are my thoughts on the subject!

Technical merits

On technical merit the JSR proposal certainly seems sound enough to be a solid starting point for discussion (I'm no expert mind you).

Open standards are good

It's a laudable goal to standardise this space, and Red Hat have got my support on that front. Just like vendor lock-in was bad for databases and app servers, it's also bad for developers and users of data grids.

This area is potentially worth Billions and so I can understand why some vendors may be reluctant to form an open std around it, but really, it's a good thing! I believe the vendors should be competing on performance and other factors, not basic get and put type API calls.

Where the proposal went wrong

Politically, Red Hat went about this in an unusual way, hence the backlash. Sadly, that sort of backlash can be enough to sink a JSR before it even sets sail.

I was a surprised that an organisation with so much JCP experience presented this JSR without the usual pre-collaboration that typically goes on in these cases. So I dug a little deeper to find out why Red Hat had gone about it this way.

The root cause

Without knowing all of the ins and outs, the new data grid JSR was proposed partly because of Red Hat's frustration with trying to get JSR-107 (data caching) back to an active state (it's been an inactive JSR for some time).

A std caching API (JSR-107) would be a natural base for any agreements around standardising any further data grid APIs on top of that.

Red Hat (and others?) had tried to re-vitalise the JSR-107 Expert Group to get the JSR re-opened, ratified and released. That would've been a great start, as it meant that there would be collaboration amongst the same vendors that are then needed for a subsequent data grid JSR.

Why did that attempt fail?

We don't really know. Unfortunately nobody on the outside can confirm what was/is going on as the JSR-107 mailing list is closed to the public!

This is the crux of the problem with the existing JCP rules, in that 'open standards' are being decided behind closed doors. Thankfully Patrick Curran is working on changing this (see! Oracle isn't always evil ;p).

So what happens next?

By raising the new JSR, Red Hat has gotten their desired result of getting JSR-107 moving again to complete the caching work. It's a shame that they were seemingly forced into this stance.  We'd all much rather see deliberate community collaboration, it's certainly not a model of how we want to see inactive JSRs moving again!

Red Hat's intentions are almost certainly completely honourable, but as some of the other vendor's stated, the raising of the new data grid JSR came across as a great surprise and was therefore not as welcomed as it could have been.


So, JSR-107 will go ahead, but it'll take some amount of bridge mending before data grid JSR gets off the ground.

Lets avoid this in the future and support Patrick Curran's JCP reforms!

Cheers,
Martijn

OSGi - Are we there yet?

A few nights ago John Stevenson (@jR0cket) and I were fortunate enough to be taken through a explanation of OSGi by some of its key proponents: Neil Barlett (@njbarlett), Zoe Slattery (@zoe_slattery) and Alasdair Nottingham.

I have certainly battled JAR hell and have also experienced problems with keeping web and enterprise applications isolated from each other (manipulating parent delegation and CLASSPATHs anyone?). This has been throughout my Java career (~10 years now), but I had never investigated OSGi properly as an alternative. Why? Because I never spent the time investigating OSGi properly and I was under the strong impression that it was better suited for IDE, App Server and tooling development as opposed to application development.

So after a good couple of hours of discussion I came out with a greater appreciation for OSGi and the following conclusions.

The Good

OSGi's core principles are pretty sound

OSGi is a sound solution for modularity, it clearly breaks the developer away from the artificial JAR model of 'modularity' and instead gets you to think about what Java packages you are dependent on. Through some simple metadata information in your manifest file you can specify the packages that you are dependent on (including a version range). For example, your test code may rely on the org.junit.core package within JUnit. Normally you would reference the entire JAR, but with OSGi you can reference just the package org.junit.core, as well as the version range that you want (e.g. 4.7.1 to 4.8.2). That package can then be supplied by any bundle (which still uses the JAR construct) which 'exports' it. You can probably already envision that a much smaller bundle can be provided than the default large JUnit JAR file.

OSGi actually encourages you to design better APIs

For those following the various clean code or software craftsmanship movements will appreciate the fact that by utilising OSGi, the developer is actually encouraged to think about splitting their public API into loosely coupled 'bundles'. The analogy here is that of Maven, which although polarises developers, does encourage them to use a correct build life cycle (clean, compile, test, package, environmentalise). good API developers should certainly look at supporting OSGi in order to help them designed better APIs

OSGi is relatively easy to get started with

You can start with an existing application and simply provide the OSGi bundle information in the manifest file for that JAR. You will tend to find that a vast majority of the dependencies already have OSGi bundle versions and it is not difficult to swap to an OSGi based build using Maven or Ant. In fact, as OSGi is already a well established technology it probably pays to have an OSGi bundled version of any project artifacts you produce. The tooling is adequate on most major IDEs (especially Eclipse) although the OSGi community would still like to see improvements in this area.

What the OSGi alliance is working on improving

A common/std tool for deploying OSGi applications to runtime environments

OSGi does have a std API for deployments, but this does mean that developers need to implement a deployment mechanism for deploying their apps to runtime environments. Most modern application servers do have OSGi container support, but the deployment mechanism is arguably different each time. This is an area that the OSGi alliance is working on and hopefully some standard tooling around this standard will come out soon. Although it seems like a small usability gap for OSGi, my guess is that this is a real adoption blocker.

Like Java apps in general, OSGi bundles are not Linux/UNIX distro friendly

A major complaint from Linux and UNIX distros over the years has been the fact that Java is not installed according to their packaging standards. Java is also an relatively large installation, which is the source for further criticism. Whilst OSGi certainly helps with the size aspect of Java-based programs, as it is also a late-binding runtime container it does not lend itself to the static, early binding packaging systems that the distros use.

As John pointed out, the existing Iced Tea (OenJDK) project does already produce bundle data that looks a good deal like OSGi bundle data:

Looking into the meta-data of the openjdk-6-jdk package, you can see there is a lot of scope for using OSGi style information.

Package: openjdk-6-jdk
Priority: extra
Section: devel
Installed-Size: 34100
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: OpenJDK Team <openjdk@lists.launchpad.net>
Architecture: amd64
Source: openjdk-6
Version: 6b20-1.9-0ubuntu1
Provides: java-compiler, java-sdk, java2-sdk, java5-sdk, java6-sdk
Depends: openjdk-6-jre (>= 6b20-1.9-0ubuntu1), libc6 (>= 2.4), libx11-6, zlib1g (>= 1:1.1.4)
Recommends: libxt-dev
Suggests: openjdk-6-demo, openjdk-6-source, visualvm
Conflicts: openjdk-6-jre (<< 6b17~pre3-1), openjdk-6-jre-headless (<< 6b17~pre3-1)
Description: OpenJDK Development Kit (JDK)

However, this does need to be investigated further and perhaps if OSGi and project Jigsaw can interoperate and some tooling is built then I could see bundles being deployed according to distribution standards. This would help Java and OSGi applications gain even more acceptance amongst the Linux/UNIX community. This leas us onto the Jigsaw issue...

The (Potentially) Ugly

Project Jigsaw (Java modularity) is coming as part of JDK 8 and at this stage is not going to work hand-in-hand with OSGi. It is not beyond the realms of possibility that the two will interoperate cleanly in the future and I'm hopeful that the two communities can continue to find common areas despite their fundamentally different approaches.

However, if they do not come together in some simple to use form then it is likely that the Java modularisation space will be fragmented which will only harm the end developer, end user and the Java ecosystem.

You can read more on this topic on a blog post by my co-author for "The Well-Grounded Java Developer" Ben Evans. This post has also been cross posted to the LJC blog.

So are we there yet?

For mainstream adoption by application developers, probably not _yet_. But I think when the tooling gap is closed and as more application developers release OSGi apps, it might just become a de-facto standard for modularity in Java apps. However, there still remains the looming specter of Jigsaw integration/interoperability. There have been signs of the two sides discussing how they can meet in the middle, lets hope that continues.

Cheers,
Martijn