In my defense the causes my transgressions are rooted in what I like to think are noble reasons. I've mentioned before that I'm a huge Jini fan. If you've become disillusioned with J2EE and you've never looked at Jini, well, you're seriously making a mistake. Whereas the J2EE spec is, what, 1700 or so pages, the entire Jini spec can be read in a couple of days. It's simple, elegant and powerful. Anyway I digress.

As cool as Jini happens to be it requires one thing that grates on me beyond measure. You see, if I write a chunk of Jini code that I want to give to you (i.e. I want to open source my code), I can't. You have to agree to something called the Sun Community Source License (SCSL). As a practical matter this is probably not a big deal. You just click through the thing, it doesn't look like you have to give up anything real, and you're in. The problem is, and this evidently is not just for me, is that it's just so damned galling. I mean, I wrote the stuff, whadda ya mean I can't just hand it out? F*** you. This is a routine area of contention in the Jini world and Sun, while seemingly quite willing to listen, seems equally unwilling to do anything to change it.

To be fair, the purpose of the license is to make sure that nobody can hijack the platform. That is, it's designed to prevent embrace-and-extend-in-incompatible ways. Technically it makes sure that, with some presumptions, your Jini can talk to my Jini. This applys, BTW, to a lot of the Java stack. J2EE, J2SE, JXTA, probably bunches of other things, either use the SCSL or something like it to make sure Java is Java. But it really pisses me off that if I even derive from net.jini.core.entry.Entry (whatever) then I have to do this under the auspices of the the damned SCSL. It remains an open question (in other words, Sun has never responded) why I can derive from java.lang.Object and give that code away, but I can't do the same with Jini code. It's a stupid and pointless distinction and it seems to demonstrate that Sun has way too many lawyers. Or something. But I digressed again.

I was looking for some sort of IDE to use to futz about with my C# experiments. I use IntelliJ for my Java work and, frankly, my ability to express myself has become very tied to that tool (this is a much longer story worthy of a post on it's own). I happened upon something called Monodevelop. It's not IntelliJ but it's something.

Now I run OSX. I love OSX. It's practical, working, desktop Unix. I do love it so. Unfortunately to get monodevelop to run on OSX I have to do a bunch of things that I don't want to do. Download some packages, install them, resolve their dependencies, run this as an X application and like that. If you've used Linux for any period of time, this is something you should be familiar with. I am. It's one of the reasons I moved to OSX. I have exactly zero interest in dealing with that crap and, while I was willing to do it to have Unix as my dev environment, I'm unwilling to do it with such a great alternative as OSX available. OSX, in that light, is very, very inexpensive for me. (Ok, this entire post has become a series of digressions. Pent up I guess). Long story short...ok, long story long, forget monodevelop for now. Maybe someone will port it to OSX and in the meantime I'll use emacs. I've used emacs for nearly 20 years so it's not a terrible choice, just not my first (never learned lisp though. Weird)

Later that day I was in the bookstore. As I do I went back to look at the geek books. Just to see if there is anything new, and also to get a sense of trends. Like how many books for C# are there? Wow, lots. Lots and lots. Of course lots of Java books as well. Lots and lots.

The geek area in this particular bookstore is organized such that I can stand back from the shelves and sort of get the gestalt of an area. All of the books on C# (and .NET) where descriptions of how to use Microsoft libraries. All of the books on Java were how to use Java libraries. And then it hit me. Java libraries (specs, actually) are created not by any one entity. It's a whole bunch of folks working to make sure that, amongst other things, the playing field is level, the technology takes as many people into account as possible and like that. And I wondered, who is going to do this in the C#/.Net world?

Sun set up the JCP to make sure that folks had a voice and that things were as fair practicable . IBM and BEA may add their own extensions to this, that, or the other, but the fact is JMX is JMX, an Entity Bean is an Entity Bean and a Jini service is a Jini service no matter where you go. Despite all it's other faults I've become convinced that this commonality, this level playing field makes the JCP worth it's weight in gold (presuming you could weigh the JCP).

You see, the monodevelop stuff, the ASP.NET books, the whole thing gave me a glimmer of what might come. And it looks to me a lot like what went before. 8 different ways of doing the same thing. Sales collateral that says "It's ASP, only better because we're so damned clever".

No doubt the C#/Mono folks would disagree very, very strongly with this sentiment. "Never happen. Hasn't happened to Linux, so neener". Perhaps, perhaps not. Only time will tell. And, to be sure, there's lots of grist for the C#/.NET mill. There are so many Java libraries to clone. I speculate there will be rather a lot of "oh, let's do it like Java spec(X)". What happens after that's done...I dunno. Who's going to be able to stand up, say "This way" and have folks follow? I can guess. I don't want to be there. Again. It's one of the reasons I'm here now.

I guess I'm coming to think that the greatest value of Java has nothing to do with Java the language, or Jini the spec. It's Java, the agreement. We (you, me, lots and lots of folks) have basically agreed to "Yah, it sort of sucks in some ways, but this is how we're going to do it". It's practical. It's works as well as most software, and it can be refactored. It seems, therefore, as reasonable as most of the code I write. If I can accept the short comings of my code, it seems sort of two-faced to not accept the short comings of the interactions of humans. Especially since both can be changed, albeit with some work.