I posted on live updating the other day, and had a commenter tell me that you could get to much the same thing in Java. Specifically, he said:

Most shops are using Tomcat for J2EE development, which has had code reloading for quite some time now (the other commercial ones like Orion have been doing this too). When I write my code I save, then reload the browser. Same as you. Please educate yourself before spreading FUD.

The problem is mostly one of understanding fully what I meant. I meant live updating of both a development time server (i.e., a test system) and live updating of a runtime server - with no downtime.

Here's what I do. I fire up the development environment for my server on my Linux box. Which, by the way, is an ancient PII 400 Mhz system. Try running any set of Java tools on that - Smalltalk, which people inaccurately call "bloated", runs just fine there. Anyway - I make my changes on that box, and test them - breakpoints in the server code, hit a service from the browser. Write code in the debugger and browsing tools, keep testing... until I get the change I need done. At that point, I take the following steps:

1. Selecting the package (or packages) that I made changes to, I use the code browser option to file-out changes.
2. Version the changes into my Store repository
3. Save the new version(s) of the changed package(s) to disk as one or more parcels
4. Upload the file from step (1), and the file(s) from step (3) to the server
5. Drop the change file(s) into a patch directory, and the parcel(s) into the application startup directory
6. Using a web interface, instruct the server to load the change file(s)

I upload the new parcels so that the next time I start the application server, the correct version of the code will load in. I start the system from a clean image that loads the entire application server codebase and configures itself. However, I don't need to restart the running server for updates - In step (6), I loaded the changes into it as it was running. Those changes might well include shape changes to classes, including classes for which there are serialized objects on disk (posts are saved as serialized objects in this server).

This gets to the real power of a Smalltalk system - the image updates every instance of the changed classes in memory. So if I have a class Post, and that class had 4 instance variables - and I just added a fifth - every single instantiated instance now has that fifth instance variable. That fact explains why I normally code my accessing methods as follows:

authorName
     ^authorName isNil
          ifTrue: [authorName := '']
          ifFalse: [authorName].

That code makes sure that the new instance variable, when accessed, has a reasonable default. For more complex cases, I'll write a script (which I load the same way I loaded the patch) which makes sure that all the new instance variables have the right sort of values.

Notice what didn't happen here - downtime. The server was running while I did all that, quite possibly answering requests. If I needed to have it not answer requests during the update, that would be easily accomplished as well - I just add more code to my patch script.

This makes Smalltalk a perfect choice for systems that need to run all the time - but also need periodic updates. The server running this blog almost never goes down - I've been updating it using the procedure I just outlined since 2002. Some of the changes have been fairly major, including changes to the way posts are saved, and changes to the HTML output from domain objects. I've also made live changes in various other things, like the way that referers are found and saved. The bottom line is - I'm able to upgrade the server in place, with no downtime. Not just the test server, during development - the production server, as it's running.