The Cave

28 Jan

JSR 291 (OSGi)

Why bother?

I looked into this at JavaOne. JSR 277 looks to solve some of the same issues — critical ones, IMO — but…

To recap, by example:
* I use Library A + B. Let’s say they’re something significant and not easily not-used, e.g. Hibernate, Spring, …
* A depends on Z version 1.2.3
* B depends on Z version 1.2.6
No big deal, right? Let’s just use Z 1.2.6+

Small problem – most Java projects (esp. open source ones) have no concept of “Backwards Compatibility”. This is not unique to Java projects, but given the preponderance of open source projects, and just libraries in general that people have access to (there may have been as many in the Visual Basic / OCX heyday, oh, wait, that’s right — we called it DLL Hell. The Java community has wound up emulating that which they so often revile — but it’s not called JAR Hell. Been there, done that – in both cases. What a mess).

So given the landscape for Java these days, JAR Hell is at least as likely as in the “good ‘ole days” of OCX/DLLHell.

OSGi (mostly) solves that problem.

JSR 277 (Modules) strives to help solve the same space.

But…OSGi is real, live, working code, with years of field experience in real world use. It’s the basis for Eclipse’s plug-in support, among others. It works. It’s proven. Sure, it’s got a few warts, but it seems it would take a small effort to smooth those out, and in ways that wouldn’t orphan existing users.

JSR 277 is…in committee. I delved into this in some detail at JavaOne. I talked to several people. I attended the JSR 277 BoF. I talked to the JSR lead.

I’m unimpressed. And not just technically.

On the technical front, JSR 277 is…young. There are hard problems to iron out. In some cases, exceedingly hard, if you’re trying to provide a solution as seamless and compatible as possible with the decade+ of existing J2SE and J2EE usage.

But…JSR 277 targets “Dolphin” (Java SE 7), and even then will only solve half the problem. There was talk of possibly some aspects could be backported and/or used in earlier versions, but only to a very limited degree given the nature of the changes planned for JSR 277.

OSGi works, today, with a few details to improve. JSR 277 will only be a half solution when it’s released, expected in 2008, and then will be significantly incomplete. Better than nothing, but largely a fancier package naming mechanism and a ‘super-JAR’ container. Which is a step forward, but still dodges the critical problem – version clash, backwards incompatibility, lack of a side-by-side mechanism, and other names. And not only is the latter a serious impediment in real world projects today, it’s also MUCH harder for people to solve on their own (the other parts are largely solveable with existing tools and processes).

So JSR 277 is technically inadequate for the critical, hard-to-impossible-to-workaround problems until “Dolphin”+1 (Java SE 8?), how many more years out? Hint: There’s not even a publicly known codename for it.

But I believe I know why. It’s not a technical problem.

I talked with the JSR 277 lead and a few committee members. I asked about the version-clash scenario.

Background: I’ve worked on enterprise class systems for >10 years. I’ve worked on Windows systems and badgered Microsoft about “VBX Hell”, “OCX Hell” and “DLL Hell” since the early 90′s. I was one of the people at SMS who worked closely with Microsoft and their Side-by-Side solution. [Dennis Castaldi, my ex-offcemate, was the primary author who penned the document to Microsoft coining the term 'Side-by-Side', and was surprised when they started talking up SxS a few months later at Tech'Ed - as if they came up with the concept and phrase.] I was one of the people who told Microsoft requriing Partitiions in Active Directory and a distinct login to get SxS behavior was a cure worse than the disease. I’ve been aware of, and dealing with, this problem for a very long time, with a very low-level understanding of the machinery involved that complicated matters.

Sidebar: Microsoft flubbed it. Massively. They added .local file support, as in notepad.exe.local, which was a minor almost trivial improvement. Why, oh why, did it have to be a zero-byte file? If it supported optional contents, as in, a hunt sequence, DLL Hell would have been nearly history. For instance, notepad.exe.local containing “C:\FOO;D:\BAR;Blah” as a 1st hunt sequence before the standard LoadLibrary order would have been a major boon, let alone something more advanced like “Prefix:blah\nSuffix:blah\nblahblahblah” or per-filename pathing like they support in “Fusion” (the plumbing under COM+ and CLR to support SxS), among other things. Too bad it’s CLR and COM+ only. And this wouldn’t have solved the ‘proxy exe’ problem (w3wp.exe is used for many diffferent ‘applications’, ditto for dllhost.exe, VB6.exe and others), but that too has solutions – symbolic links a la Unix and ‘proxy context awareness’ being two of them. Too bad Microsoft never did this, it would have saved a lot of headaches – and maybe even some customer and developer loyalty. Ah well. Reap what you sow…

So yes, I have some experience with this issue. I was interested, knowledgeable, and motivated.

I got brushed off.

The JSR lead in particular (I forget his name offhand) was a real prick about it. I asked about the SxS scenario – the fundamental and thorny problem in this space – and he blew me off. (And a few others in the JSR standing around) acknowledged it’s a problem (once they understood the scenario – scary part: I had to explain it, in detail. They didn’t know it and kept proposing ‘solutions’ that weren’t. Which is telling in its own right, but that’s another issue.) The lead told me the spec would make things clearer, I asked where I could find more info so I could come up to speed and, if my concerns weren’t addressed as a I feared, contribute to the dialogue. I was told the spec will be out in ‘a few weeks’. I said great, but then it’s pretty much locked down short of a major catastrophe, can I get a copy sooner, and I was told the JSR materials are not public until that spec comes out.

Let’s recap:
* I’m not a member of the JSR (and wouldn’t be able to join any time soon)
* JSR material was private
* By the time the spec was publicly accessible, it’s pretty much locked down and just looking for refinements
* OSGi, a seemingly working solution, is being ignored in favor of a totally differnet solution from the ground up
* JSR 277 wouldn’t ship for 2+ years (JSE 6 wasn’t expected for another 6 months at that point, let alone 7)
* JSR 277 would only solve half the problem, and not the realy important one
* The spec lead had an attitude of “Go away, you bother me” and couldn’t wait to get away, despite my obvious experience and understanding of the issues involved

It’s that last part that particularly troubled me. If the lead is very closed and insular, it doesn’t bode well for the end result.

I’d heard JSR 277 had some…political issues, in committee. For such a fundamental and far reaching problem, a small, closed-knit group designing a solution largely on their own is not a good sign.

Needless to say, the attitude was a major turn-off. I went from a very intent, interested and motivated potential helper to having ZERO interest in helping JSR 277.

I’d say their loss, but in the end, it’s all our loss.
Well, if you use Java.

Oh well. At least there’s OSGi. Which, to be honest, is a pretty sweet consolation prize :->

And what is the moral of the story: Kind words and a perception of being open and responsive will garner a lot of success and goodwill than dismissiveness and closed minded attitude. Even if it’s merely the perception of openness with no real change day-to-day, the good- (or ill-)will generated pays far more dividends than the actual work.

In short, being nice will get you farther than being a prick.

FacebookGoogle GmailGoogle BookmarksTechnorati FavoritesTwitterHotmailYahoo MailYahoo MessengerWordPressStumbleUponRedditEmailInstapaperGoogle+Share

Comments are closed.

© 2014 The Cave | Entries (RSS) and Comments (RSS)

GPS Reviews and news from GPS Gazettewordpress logo