Popular RFE

My favourite sunbug is now on the list of the Top 25 RFEs (Requests for Enhancement).

The 11th most popular sunbug?

Sunbug 6650394 is coming along nicely - both in terms of votes and supportive comments. At the time of writing, it has 99 votes, so thank you if you took the trouble to vote! If you care and you haven't yet voted or commented, please consider doing so.

I was hoping the bug would make it into Sun's Top 25 Bugs list since it has more votes than most of the bugs in that list, but for some reason it's not yet included. If the list was accurate, which it clearly isn't, then 6650394 would be the 11th most popular sunbug.

Sunbug for JSR 277 module system interoperation

Sun has kindly raised sunbug 6650394 on my behalf to track the module system interoperation issue for JSR 277.

Please consider voting for this bug if you would like JSR 277 to interoperate with JSR 291 (OSGi). Add yourself to the watch list if you want to track the bug.

Hope for interoperation between JSR 277 and JSR 291

Infoq and Alex Miller picked up on my recent comments about the somewhat closed approach being adopted by JSR 277. Since the whole concept of interoperation between JSR 277 and JSR 291 seems to be doubted, I thought I'd better provide some reassurance.

The saving grace of both these JSRs is that they ultimately boil down to delegation networks between module class loaders. So there is a lingua franca lurking not very far under the surface. Granted the views presented to the module developer are quite different in detail.

Quite a while ago, I wrote a prototype module system interoperation framework, described in more detail here, to start to flesh out how these JSRs could interoperate. I regard it more of an existence proof that a reasonable solution may exist. However, it requires 'cutting' into the module systems at a deeper level than I think is currently being considered by the JSR 277 spec. lead and colleagues.

We discussed some of the options in an informal Expert Group meeting at JavaOne, but all we really concluded was that there was a lot of work ahead to get interoperation working smoothly. I think there is also a consensus among the interested parties that reasonable interoperation is essential to the success of JSR 277. So the sooner we can get more eyes, and brains, on the current proposal, the better.

JSR 277 and JSR 291 Interoperation Strawman

For anyone who's interested, I contributed a strawman module system interoperation framework to Apache Felix for discussion there and in the Expert Groups of JSR 277 and JSR 291. I hope we can make these module systems work well together...

See a post to the JSR 291 EG mailing list and docs/README in the JAR attached to the JIRA issue for some technical background.

Is full interoperation realistic?

Wouldn't it be useful if applications could communicate over a network using a standard message format and protocol? Wouldn't this solve a lot of real-world problems, especially if the whole thing could be kept simple?

Sure, but before long you'd have to address the 'full interoperation' requirements: distributed transactions (so application programmers don't spend most of their time writing error handling logic), security (for sensitive data), a directory server (so distributed applications can find each other; ideally secure and transactional), load balancing, distributed debugging, etc.

And since real world systems don't all run on a single vendor's hardware or software, most of these features would need standardising so applications running in different environments could communicate with each other.

Now if the probability of each feature interoperating correctly was, say, 99.9% and there were, say, six features, then the probability of all six features interoperating correctly would only be about 99.4% (0.999⁶).

You'd end up with a system that would be much more complex than was originally envisaged and the interoperation wouldn't be great.

But, hey, what if you stepped back and came up with a standard message format and protocol so that applications could communicate over a network? Wouldn't this solve a lot of real-world problems, especially if the whole thing could be kept simple? Indeed it would ... if.

Many vendors are following the full interop. model with the likes of CORBA (e.g. via Java EE) and SOAP. Others, notably Microsoft, support full interop. but would much prefer a homogeneous (software) network also viewed as 'single vendor lock in' (or world domination).

I don't think there's a perfect, multi-vendor solution, desirable as this would be. The most flexible approaches that I've seen work in practice are distributed systems consisting of homogeneous 'islands' loosely connected with relatively simple protocols (such as MQ Series messaging, IIOP, or vanilla SOAP).