It's about time, and a little less about space
I'm renewing my passport. The process is pretty easy: you send your old passport, along with a couple of new pictures and a completed form (plus $60) to some place in Pennsylvania and, at least in theory, you get back a new one. Filling out the form was the sticky point with me. I got to the point where it said hair color and I began to write brown out of habit. I then glanced at the pictures taken that day and muttered to myself, "who am I kidding?" I reluctantly wrote gray and moved on.
I realized I'd been doing this stuff for a while. When I was working at a little company in Cambridge, Massachusetts in the Java 1.02 days, I suggested that we use Java to produce the web pages for our medical information website. The reaction was roughly that's just crazy talk! So, I prototyped something that showed how it might work in our web server. Objections followed that you couldn't get access to the environment variables (the standard way to accept parameters for a CGI), it would be too slow, and, generally, it was a really stupid idea.
Well, I do have really stupid ideas occasionally (something my closest friends remind me of on a regular basis), but this wasn't one of them. I suspect a great number of web pages each of us view every day had Java somewhere in the mix. But in those days, the idea was new and, sadly, even in the most innovative environments (or those that believe they are innovative) new ideas are not always welcomed. Being stuck in a rut in an occupational hazard for the software industry.
There are plenty of examples people's thinking stuck in a rut:
- I couldn't get my boss to give Java a shot at being an integral part of our web infrastructure
- The initial Sun Jini marketing team thought listening to the engineers who actually built the thing was optional and tried to convince the world "Jini is (only) for devices" (a horrible myth that persists today)
- Java is slow
- Java's too big and clunky for desktop applications, you need to have "native" code
- Java can't do real-time stuff
The last point, Java can't do real-time stuff, is a myth that was hopefully busted today by Greg Bollella, Distinguished Engineer at Sun, and David Hofert, Group Marketing Manager at Sun. Bollella has a new version of the real-time Java system called Project Mackinac (Sun's RTSJ implementation) that looks very, very promising.
One of the big problems you need to solve for a real-time system is predictability in your scheduling. If you've got a little piece of code that needs to run every 10 milliseconds then the scheduler needs to guarantee that will happen. Think of these relationships as little contracts: the scheduler promises that you'll run every X milliseconds and you promise not to take longer than Y milliseconds when it is your turn. Everybody plays by the rules and stuff gets done in an orderly, predictable way. That's the time part of the equation.
The space part of the equation is a little more tedious. The short answer for this is to have an arrangement for your memory that gives an allocator and garbage collector a chance to play by the same rules that your code plays by: a promise by the scheduler to run the garbage collector every so often, and a promise by the garbage collector to finish on time (and make sure memory is available, thank you).
I like what I see (but I'll need to read more). Here' s what I'd really like to see: Java-based technology running in real-time safety-critical applications. GASP! Lots of serious safety-critical people have now written me off as a complete nut-ball. That's OK. It wasn't that long ago that people thought everything important should be coded in assembly language because we couldn't trust compilers. I don't hear that argument much anymore... unless, of course, their hair is even more gray than mine!
Today the safety-critical stuff is probably done in C or Ada or assembly language. The particular stuff I'm thinking of is software that would fly on an airplane. There is nothing magical about C or Ada; these languages simply provide a code base that is relatively easy to analyze and review. Object oriented languages (principally C++) are only now gaining a measurable level of acceptance--but only with static allocations of objects done at start-up and none later.
The rule, in short, is no surprises. If the failure of a piece of software has the potential to bring about injury or loss of the aircraft and lives, then that's pretty serious business. And, at 30,000 feet there's no place to pull over to fix a problem. I understand completely the reluctance to do anything fancy and new for application areas like this. That said, there are benefits of OO and Java that could help developers produce safer software, more robust software, and more maintainable software. We will have to be sensitive to the safety-critical industry's concerns; they must be open to the possibilities offered by a robust and powerful real-time Java. There is a lot to be gained in both camps.
My wish will not come true for a while. There is much work ahead to make that goal. I'm willing to hear about all of the challenges to be faced from people bringing enthusiasm and energy to the table. I'm less willing to listen to nay-sayers who are stuck in one of those ruts described above. Not to put too fine a point on it, I'm getting to old for that!
This is a fine time to remind everyone that anything I post here is my opinion and not the opinion of my employer, my friends at Java.net, or indeed anybody else on the planet.