Spice is Not a Recreational Drug

Thumbnail image for Recreational-Drugs-Are-There-Any-Other-Kind-Posters.jpgWell, it seems our friends at Sun have decided that their Spicetm Enhanced brains are completely sufficient to create an entirely new – but far simpler, mind you – module system for the JDK.  Mark “I’m just a simple Guild Navigator” Reinhold has spent a number of blog posts doing the electronic equivalent of the Dance of the Seven Veils, culminating with revealing the aptly named Project Jigsaw.

First off, what Spicetm Enhanced marketing mind came up with the name Jigsaw?  I mean, really.  Who thought it would be a good idea to associate a “simpler” module system with a 1500 piece puzzle set that is composed of pieces that look terrifyingly all similar and takes multiple people multiple months to put it together?

Marketing brilliance!

But this, of course, is really just the beginning of the insanity.

Sadly, I’m not at liberty to discuss all the various details of the briefing that Sun put together for us at House Harkonnen (and other great houses, I’m led to believe).  Like almost all of the application of secrecy, the geas that Sun has put on me is largely designed to protect them from embarrassment, not to hide any great mystery that shall not be revealedtm.  Whatever.

But what I can reveal is my reactions to the great and hermetic secrets that Mark Reinhold, himself, presented to the collected assembly in the offices Barron Harkonnen provides his vassals for such meetings.  And my reaction is summed up in the phrase, common in the country of my birth:

Don’t piss on my leg and tell me that it’s raining

Over the years I’ve come to rely on a single heuristic – a principle, really – that has kept me from being suckered by time wasting morons and their projects doomed to failure.  The heuristic is simple:

Good ideas don’t need a lot of lies told about them to gain public acceptance

Now, perhaps the word “lie” holds too much emotional impact, so I will not characterize anything that Sun has told me on the subject of modularization as a “lie”.  However, the “facts” and presented evidence from Sun on the subject has clearly skirted the fine line between dissembling and misleading.

For example, in the discussion with House Harkonnen, Mark presented a series of what he referred to as “requirements” for the module system, which in satisfying he was reluctantly led to the conclusion that OSGi would simply not work.  I put the word “requirements” in quotation marks because it was quite clear that the list that Reinhold presented was not in any way properly characterized as a list of “requirements”.  Rather, what Reinhold presented was simply a list of solutions.

Now, living in the valley as I do – and perhaps more to the point, being a resident of the Emerald City of the valley – I’m quite used to people presenting solutions as requirements.  In this industry, it’s hard to find anyone that simply doesn’t think about the actual problem, but instead thinks about their shiny solution and presents the solution as the requirements of the problem.  Fair enough.

But what Reinhold presented wasn’t simply a list of solutions.  It was a list of solutions that appeared to be specifically designed to eliminate OSGi as a solution to Sun’s desire to modularize the JRE.    Now, I’m certainly not one to believe that OSGi is the be-all and end-all glorious solution which cannot possibly be changed in any way.  There’s a great deal of very cool things that could be done with OSGi in this space that would result in changes that would be very good for OSGi.  But the list Mark Reinhold presented was not among them.

Pretty much every single “requirment” that Reinhold presented (and Mark, if your reading this and want to release this from NDA so we can actually debate it in the open, I’d be thankful) was immediately solvable in OSGi.  A rather irritating pattern of the presentation was the phrase “I’m not an OSGi expert” which was then followed by making a declarative statement about OSGi and how it wasn’t up to solving the particular “requirement” gathered by the Third Stage Guild Navigators of Sun.  Now, maybe I’m old fashioned, but I think that if you aren’t an expert in a particular subject, then you probably shouldn’t be making declarative statements about what can and cannot be done in that area – especially if you’re affirming that you aren’t familiar with the subject at hand.

But I guess the Spicetm Enhanced minds at Sun can break those rules because they can see far into the future and navigate the threads of futures past and come to concrete conclusions based on their opinions.

So, let’s just end this post by reviewing some simple facts.  Sun is abandoning JSR 277, the Java Modularization Specification.  A specification that received universal scorn because Sun wasn’t paying attention to OSGi, I might add.  A specification that was widely regarded as an “Not Invented Here” response by Sun to pee on the Modularity real estate because they believed that they could do a better job than OSGi.  So now, having failed in that attempt, they’re taking their ball and going home to the “Open” (snort!) JDK where they conveiently own the entire governance such that they don’t have to listen to anyone else in creating their uber module system.

Further, they’re going to create a bait and switch for the rubes in the Java community by foccussing their modularization efforts in JSR 294.  What this means, of course, is that while Sun is busily creating, marketing and pushing the module system of JigSaw, they hope to keep everyone occupied with the bright shiny baubles they’ll dangle in 294 where committees of people who haven’t actually used a module system such as OSGi  (name another one!) will fight over how many baubles they can lay claim to.

Oh, this reminds me of another bit of dissembling from Mark Reinhold regarding JigSaw.  Repeatedly, Reinhold characterized and stressed that JigSaw was an “internal” module system, not really meant to be used in the wild – in “applications”.  The impression that Mark was trying to leave with us was that this was just an implmentation artifact that would be largely hidden and unseen by the mass of Java programmers out in the real world.  When I finally had enough of this horsepucky, I pointed out that this was clearly bullshit and that they were, in fact, going to be pushing this as a modular solution that applications can use.  Mark’s dissembling on this issue was literally so bad that one of the gentlemen from Sun – I forget his name at the moment – literally stopped Reinhold and told him that he was being disingenuous in characterizing JigSaw as purely an “internal” system – that it clearly was going to be pushed and used outside of the JRE, in application land.

Again, you don’t need a lot of lies to gain acceptance for good ideas.

So, it’ll be interesting to see what becomes of this great effort on Sun’s part.  It’s pretty clear to me that Mark Reinhold, at least, certainly has a chip on his shoulder regarding OSGi – I believe Mark stated that he wasn’t going to go to OSGi, hat in hand, and negotiate this stuff.  Whether my reading of Mark’s attitude is correct and whether this attitude reflects a general feeling at Sun or not, the problem with this whole “module” fiasco has been simply the inability of Sun to recognize that there already is an existing and quite mature module system for Java in OSGi.

And so we’re left with the hilarious practice of living with the Second System effect, where Sun – while not actually having actually used the technology in question – is going to produce the “real” version of that technology using their Spicetm Enhanced brains…   It’s not necessarily a form of insanity endemic to Sun, per se.  Certainly this “not invented here” syndrome is prevalent in our industry and certainly is well ensconced here in the Emerald City where I spend my work hours slaving for the Barron.  But really… isn’t it time that this stupid shit stop?  I mean, does Sun – and Reinhold in particular – really think that they are so frickin’ brilliant that they are going to produce something that is even measurably better – and of measurably higher quality – than OSGi?  I guess they do.

The unfortunate effect is that, due to this hubris, we’re now going to have to deal with the fallout.

It’s kind of like sending 200,000 troops to Kuwait: Facts on the ground.  After all, we have this existing module system now, what makes you think that Sun will now have any incentive to make it c
ompatible with OSGi at all?  If they wanted to do so, they could have done so in the first place.  The Apache Harmony project is proof positive that OSGi can be used to modularize the JRE.

If you start off by claiming that you’re not going to negotiate with OSGi about any of this, then it shouldn’t really suprirse anyone at Sun to see people rolling on the floor, laughing at their assurances that they’re going to work really, really hard to make the system compatible with OSGi.  I mean, really Mark.  Pull the other one!

4 thoughts on “Spice is Not a Recreational Drug

  1. I (naively) expected to have a module system in Java with automatic dependency resolving by JDK 6 and I (naively) expected for this system to be OSGi-based.
    My guess now: 2010 & not OSGi-based
    Bad news for Java…

  2. Well, you have a module system in Java with automatic dependency resolution, existing today in the form of OSGi. I don’t know what you’re waiting for…

  3. Interesting that the original specification for the OSGi service framework came from Sun Microsystems. They let it out into the open community and lost control of it so now they want to create something new and untested to they can regain control?
    Greg P. should be ashamed of letting something this stupid happen.
    John Barr, One of the founders of the OSGi Alliance

Comments are closed.