If you add the Tomcat web applications server to the mix, you have a beautiful development environment for web applications. You can store actual Java objects in a session object -- including running task objects! This makes it extremely easy to do things like, e.g., monitor a running job by periodically refreshing a web page... all you have to do is stash your running job in the session object, fetch it in your monitor .jsp, and display the public status variables (that you previously defined and are updating in your running job as needed). No hitting the disk (the session objects are stored in memory, since Tomcat is a multi-threaded environment, *NOT* a multi-process environment).

Heck, Java even handles many of my hesitations about threads. Not all of them -- e.g., how the heck can you cleanly "ask a thread to die" if the thread is stuck in an endless loop? And it's impossible to do a 'kill with extreme prejudice' on a thread without worrying about hung semaphors. But if the object being used is 'synchronized', you don't have to worry too much about hung semaphors, the language (and runtime) handles it for you. So multithreaded programming in Java, while not as reliable as multi-process programming in Unix/C, is still a heck of a lot more reliable than doing a multi-threaded C++ program.

Now, I hear you rumbling right now, "If Java is so great, how come Linux people don't use it?". And therin lies a tale.

A couple of years back I was looking for an implementation language for a multi-platform project. I discarded Java and chose Python instead. Why? Because with Python, porting my application environment to another platform was just a matter of " tar xzvf python15.tar.gz ; cd python1.5; ./configure; make; make install". With Java, unless it was one of Sun or IBM's officially supported platforms, we were talking about having to get a source code license from Sun, then porting Java. Bleah. We wanted to write an application, we weren't interested in porting Java.

In other words, Java has one, and only one, problem: lack of source code.

The beauty of Open Source is that whatever platform you're thinking of running it on, somebody has already ported it there. So if you're a developer, and you want an implementation language for a project, it makes sense to use something like C or Perl or Python that exists everywhere.

But Sun didn't want to play it that way. They wanted to hold Java close to the vest, figuring that would keep Microsoft from co-opting it with Embrace and Extend. But all they did with that was make Microsoft re-invent the wheel with C#. In short, all they managed was a delaying action.

Until there is a good Open Source implementation of *ALL* of Java, including (especially) the libraries that make it so popular, Java is doomed to be stuck in a few niches like "web server backend" where the fact that its lack of source makes it unportable doesn't matter. Sun shot themselves in the foot when they did not release Java as Open Source. Sun continues to do so every day that they pretend that keeping the reference implementation and its libraries under a restrictive license actually accomplishes something useful.