Tensegrity

I am of the opinion that no one actually sets out to do stupid things.  Rather, stupid things happen almost invariably for the best of intentions.  Thus the phrase "The path to hell is paved with the best of intentions".

And so it goes with standards.  In the past week, I've been privileged to witness two crystal clear examples of first class paving of the path straight to the gates of hell.  The root of both of these examples is the simple fact that the specification organization doesn't have a process in place for dealing with the changing of a specification after it has been accepted as final.  Basically, in this organization, the "final" version of the spec is presented to the members, and the members vote on whether to accept it.  Sounds simple, right?

Well, the devil is always in the details and due to the way these things are scheduled, the reference implementations and conformance tests for these specifications aren't finished at the time that the members vote on the "final" version of the specification.  Consequently, if anything shows up in either the creation of the RI, or in the creation of the conformance test which is to verify that the behavior in accordance with the specification, there's a serious problem that needs to be resolved.

In the two cases I've been privileged to see this week, the first was an issue with time.  As with all things, resources are limited, and certain resources are scarcer than the sympathy in a banker's cold, dead heart.  Consequently, when the time pressure to produce something gets unbearable as the deadline approaches, the reality will set in and like survivors on a sinking lifeboat, everyone starts looking for stuff to throw overboard.  And because this process is done under pressure, there's not an awful lot of thought and strategy put into the choice of what is being chucked overboard.

From my own point of view, I continually say lines from movies, expecting people to understand their applicability to the current context, but given that I often find myself looking at a lot of confused, blank stares when I say these things without explanation.  Consequently, I show the image on the right as context.  It's a scene from the movie Groundhog Day.  In this scene, Bill Murray's character is going to kill himself for the umpteenth zillion first time by driving a truck off the cliff of a quarry.  As you can see, the groundhog is actually driving the car as the police are chasing them at high speed.  The line in question - i.e the line I would say which would then draw blank stares - is what Bill Murray's character is saying to the groundhog at this precise moment in the scene:

"Don't drive angry!  You should never drive when you're angry"

And that's pretty much what I would say about tweeting when you're angry: don't do it.

This week at EclipseCon, I discovered that I had inadvertently opened a can of worms and found the entire Landsraad of the Open Source community arrayed against me.  My crime?  Apparently it's simply that I've had the audacity to pick up an OSGi specification that has been in existence - and in the public domain - since 2005 (i.e. OSGi RFC 112, the OSGi Bundle Repository) and attempt to work out the issues with that specification so that we can finally formally release it as part of the OSGi specification.

Much of the suffering I was dealt was due to serious misunderstandings of those involved with the process that is currently being played out.  Some of this misunderstanding is due to ignorance of the OSGi process - and note that I use the term "ignorance" not as a pejorative, rather simply as a statement of fact.  Those who aren't involved in the OSGi process, nor familiar with the way that specifications in general are produced can sometimes be left bewildered by the array of TLAs and the process by which consensus is reached.  Certainly in the Open Source world, sometimes things are done quite differently than they are done in standards bodies (note: I'm not saying that this is universal, only making the point that standards bodies are their own beasts and Open Source communities rarely conform to such formalized systems).

So let me make a couple of points, and talk about how I'm going to carry out the process of specification of the OSGi Bundle Repository to ensure that the world outside of OSGi can participate in this process.

My first thought was that it seems like a lot of money to ensure that OSGi is used as the module system for Java.

Well, it seems our friends at Sun have decided that their Spice^tm 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 Spice^tm 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.

So, this morning my alarm clock was inexplicably set to the central time zone and consequently I arose 2 hours before my regularly scheduled time. Unable or unwilling to go back to bed after my morning "get ready for work" rituals, I settled down to read a few articles from my RSS feeds. The first one I read was a rather odd post on Distributed OSGi - Tilting at Windmills by Roger Voss. Laughing a bit as I read the opening paragraph, I didn't think much more about the post as it really had nothing to do with what the OSGi RFP 119 "Distributed OSGi" really is about. Fortunately or unfortunately, several people started peppering me with tweets, IMs and emails asking if I had read the post in question and what were my thoughts about it. So, here they are.

Basically, I'm not really going to defend the OSGi EEG RFC 119, "Distributed OSGi" as my own interest in the matter rested largely with the acquisition of the so called "registry hooks" which allow infrastructure developers such as myself to hook into the queries of the OSGi service registry and do cool things like manifest services on demand. Once this capability was present and decoupled from the 119 RFC, I felt I had all the tools I needed to do any damn thing I wanted to, regardless of what the 119 RFC was doing. (for background as to how I fell in love with the idea of the registry hooks, see my posts on remote OSGi, which predated the RFC 119 here and here and a post during the formulation of the RFP which led to RFC 119 here)

Well, after my last blog entry regarding Sun and JSR 277, I received a visit from the enforcers of that fine establishment. Wearing heavy overcoats on a nice sunny day, the elevator door opened and they came rushing out. Like a scene from the Matrix, it seemingly took them forever to pull out their impossibly huge automatic weapons they had hidden under the black leather trench coats. In only several hundred milliseconds, Sun's professional enforcers unloaded 20 or 30 pounds of lead in the form of hundreds upon hundreds of rounds of high powered ammunition into what used to be my body, splattering my physical essence across the interior of the reception area of building 200 on the Geidi Prime campus.

Or not. Rather, what did happen was Alex and Stanley showed up at my office escorted by a fellow member of House Harkonnen and after a slightly awkward moment with Stanley (I had, after all, just blasted across the internet - with the awesome power of my blog - stating that he was an idiot), Stanley and my compatriot excused themselves to work on JSR 277 related specification business leaving Alex Buckley and I in my office, as I watched him finger a menacing looking lead pipe that he pulled from his brief case.

Or not. Rather, we sat down and talked comfortably for quite some time about about everything but the issues surrounding JSR 277 and the reason why Alex even knew of my existence. Eventually, however, we directed the conversation towards the actual issues we really needed to discuss and left the safe domain of my Dr. Who toy collection and the pleasantries of traveling through Heathrow in the U.K.

Stanley Ho shows up for another meeting of the JSR 277 Java Modules Specification with a brand new versioning scheme

Dear god, why are we subjected to such hubris?

Stanley Ho, working on the Java Module System (formerly known as JSR 277) has decided that Sun is so smart that they need to invent yet another versioning system. Now, maybe Stanley Ho really is a super smart dude who makes me look like I was a fifth rate, multiple generation inbred dufus from the white trash mountains of Virginny (many, many people have actually pointed that I actually am a fifth rate, multiple generation inbred dufus from the white trash mountains of Virginny, but I digress), but it seems to me that it is self evident that versioning is what we in the business know as a HARD PROBLEM^tm. And to think that someone even as super intelligent as those people at Sun are known to be will come up with a scheme that doesn't have any unintended consequences that were not foreseen by even their Spice^tm enhanced brains is simply something that I think you'll find many in this industry simply can't conceive.

There will be bugs in what Stanley has designed. There will be unintended consequences. It will only be after years of serious use and abuse by many hundreds of thousands of developers in real world situations that even the Spice^tm enhanced mind of Stanley Ho hasn't dreamed of will the full extent of his hubris become clear.

One might ask the question: "Why, Stanley, didn't you use the OSGi versioning scheme?".

<crickets chirping>

This shit is hard. This path is fraught with peril. In the 21st century, we simply don't go around inventing shit for the hell of it simply because we can. We reuse existing things even though they might not be the correct shade of purple we were dying to have. Simply because the corners are a bit worn.

The absolute last thing we need from Sun in the Java Modules is Yet Another Brilliant Sun Shiny Invention that we'll have to suffer though for years until all the bullshit is extracted from the hubris that went into creating.

Geebus. Please. Dear God. Please.

Stop the madness. Someone please hold an intervention with these people. The industry simply cannot stand to have this crap thrown at them, especially in something as fundamental and as far reaching as the frickin' base Java module system.

See Peter Krien's rant on the hubris that is Stanley Ho.

Sometimes a turd is just a turd

So I finally have what I consider to be the minimum - bare minimum, mind you - bar of the 3rd Space gaming framework finally passed. What I have working is a Predator/Prey simulation using the Boid rules for modeling flocking behavior. Boids were invented by Craig Reynolds to model the flocking behavior we see in birds, fish and other herd animals. The rules in Boid are actually butt simple and all local - i.e. simulating the flocking behavior only relies on the emergent behavior of the individual's action, not some "higher authority" guiding the individuals, keeping them in formation.

In any event, what you find if you look for any Java code which implements Boids, the seeming universal implementation is to actually keep a global list of the boid positions - i.e. an implicit "global" which really shouldn't be present. The reason why this is so is, of course, because Area Of Interest management (AOI, for short) is a tough thing to do, even if you are simply running the simulation in a single process.

> Predator/Prey Boids, using Voronoi based AOI management in an event driven simulation

I really needed a non trivial simulation to use as the driver test case for the 3rd Space gaming framework I've been working on. Flocking behavior is, as one expects, quite common in games and is something that the human players do quite frequently as well - they don't call humans sheep for nothing. As it turns out, managing the area of interest for simulated entities and human's avatars is rather difficult precisely because of this tendency to flock. Moving, flocking simulated entities is therefore the de facto test case that one should be using as a model when developing the basics of a large scale, distributed simulation and gaming infrastructure - i.e. if you can't handle this, then you have no hope of handling anything more complicated.

Same as above, revealing the voronoi overlay used to maintain AOI.

So, it's kind of cool. I now have a non trivial simulation which runs under both the event driven framework and makes use of the voronoi based AOI management. Next step is to now distribute the simulation using Coherence so I can see how well my theories of how to massively scale this framework will work.