Okay, I have to confess that I didn’t think I was taking Bob to the woodshed in my response to his response to my interminable screed. But he’s a good sport (haven’t spotted any wolf packs nipping at my heels, yet) and follows up the initial serve with some good points worth thinking about.
One of things that Bob throws out in his post is a rather interesting product called Java Rebel that bears watching. It seems like very interesting technology and I’m quite curious as to what it looks like under the covers.
But going to the meta point that Dr. Pasker seems to be pointing at, I just happened to read a rather interesting article who’s topic seems quite germane to the discussion at hand: Multiprocess versus Multithreaded…or why Java infects Unix with the Windows mindset. I highly recommend anyone interested in this kind of stuff read that post as I think it does speak to the heart of the issue.
One of the eternispecs has been the Java Isolate spec – JSR 121. It’s always garnered a lot of interest and at one time, some sound and fury was directed towards it. But it’s something that has yet to find its way into the outside world.
Between the two topics above – Java as a Windows mindset and Isolates – I think that one can get a pretty clear picture of what’s going on and where the essential issues lay. The problem is simply that we’ve effectively eliminated the process out of the Java model without providing the required support within the model for the work that we’d like to do which is desperately seeking a process model.
Back in the day, one of the projects I did was the rather mutant Java application server which ran in House Harkonnen’s database. For those of you who don’t remember the beast, let me stress that the model was rather different than what you find in modern application servers – thus the reason why it failed miserably. The model was that the actual Java VM ran in the database session. The great thing about this model was the isolation given to the running Java application. You could manage all of its resources precisely and do all sorts of neat stuff with it. The bad thing about it the model was the isolation given to the running Java application. See, it turns out that pretty much All Computing Is An Exercise In Cachingtm and consequently having the level of isolation between users and applications that we had in this application server drove programmers nuts – literally as some had to check into the emergency room after a week long beta camp.
One of the things we had to solve in this Java VM which ran in the database was that with this level of isolation – remember, the VM ran in the database session and had the same isolation semantics as a database session – was the sharing of what amounted to read only data between all the instantiations of the VM. In my case, I was starting up a VM and bringing to life Servlets and EJBs out of nothing in response to the first connection of a user. What we found is that the vast, vast bulk of the time we were spending on spinning up the VM was all the constant, read only data. Java, as it turns out, doesn’t have CONST and consequently has to cons up a huge amount of crap just to get the system up n’ running – for example, every Locale known to humans, whether you needed them or not. And so, to make a long story short, we created the concept of shared, read only objects that we could share between invocations. It sped up start times dramatically, but still didn’t solve the sharing problem we had between users.
So, this terrible experience of building something that was a complete flop left me with emotional scars too terrible to contemplate, but also provided me with a healthy respect for the issues involved in creating the kind of isolation that we all seem to crave in this infrastructure community.
Myself, I’ve come to believe much more in the Unix Process model camp than I do in the Microsoft Windows Thread camp – although I am certainly not someone who could speak with authority on the final word on this subject, by any means.
A couple of issues I think need to be brought up with respect of where we currently are in Java. The first is the hopefully obvious fact that we didn’t know what we were doing when we built the concept of the Java application server, ensconced as it were in the J2EE specification. Being one of the guys who was responsible for the first version of the spec, I can personally witness to the confusion and stupidity (and I mean that in the nicest way) we all brought to the table in building that specification. I mean, you look back at the history of J2EE and the first thought I usually have is “My God, what have I done?” (to quote David Byrne).
However, luckily I believe that we have far better models today. Most notably, the OSGi model. I’ve given a long talk on OSGi (which really only scrapes the surface of this wonderful spec), and this post is already longer than a blog post should ever be, so I won’t reproduce it here. But one thing that should stand out is that OSGi was designed – from the ground up – to do some of the kinds of things that Bob is talking about. I’m not sure of what kind of technology Java Rebel is using under the covers, but I can tell you that we can already do this in OSGi containers today. The OSGi Bundle is a set of java classes and resources that has a true lifecycle, meaning that you can cycle it out of the container quickly and update it with a new version transparently. Seriously cool stuff that’s really only the tip of the ice berg…
Jeesh… This post is way, way too long so I’ll leave things here where they stand and start to think about responding to what I thought I was actually going to talk about wrt transactional memory, thread control, etc., in the next post on the subject of JPIE.