The Importance of Hotswap

One of the more disappointing part of the JVM Language Summit was our general failure to convince anyone else of why it’s important that the JVM be able to hotswap changes.

In general, I don’t think anyone there would have disagreed that being able to change code on the fly is critical to the ability of developers to be productive. While it’s sometimes nice to do so in production, it’s fairly critical in development, especially when you’re developing server applications or desktop applications that take a non-trivial amount of time to start up and get into a state where you can test your changes. Both for iteratively developing new features and for fixing bugs, the ability to immediately test out changes after writing some code is critical both for saving time and for preserving attention and flow. Spending a minute taking a server down, spinning it back up, and getting back to the appropriate part of the application is both a time sink and can easily cause you to lose your concentration while you wait. (Incidentally, avoiding that loss of concentration is also a key reason why it’s critical that tests run quickly.)

The dynamic language community knows this already, obviously: that’s a large part of what “dynamic” means in that context, and one reason why people are often more productive in dynamic languages. There’s often a confusion, though, between a “dynamic language” and “dynamic typing,” even though the two are often conjoined: there’s no reason why a statically-typed language can’t be evaluated/compiled on the fly and then changed on the fly as well, it’s just that the mainstream statically-typed languages don’t really allow for that.

But wouldn’t the world be a better place if they could?

The attitude towards hotswapping on the JVM that I essentially got was something along the lines of “I don’t care because it doesn’t affect my language.” I guess that’s only to be expected: pretty much every dynamic language on the JVM has already had to find some way to allow for dynamic class changes at runtime, generally by not creating standard Java classes for things but instead using techniques like generating method snippets in their own anonymous classes in their own classloaders, creating their own root object hierarchies, and handling method dispatch themselves. If you want to support dynamic typing, you essentially have to do all of that anyway, so you don’t really care about class reloading.

But what about statically-typed JVM languages (including Java itself, Scala, and our language Gosu)? We try to compile down to classes that are as close as possible to standard Java classes so that we can ease interopration with Java, achieve Java-level performance, and interoperate seamlessly with standard tools like Java debuggers and profilers. Doing that, however, means that if we want dynamic behavior we’re at the mercy of the JVM’s class reloading behavior.

The Scala guys obviously care about this: they have a free license from JRebel to essentially attempt to replicate what the JVM should and could do internally via hotswapping, so I’m surprised none of them seemed at all concerned about hotswapping.

The thing is, this is essentially now a solved problem: The Dynamic Code Evolution patch to JDK7 is ingenious, it makes hotswapping work with arbitrary changes, and it’s stable enough that several of us (and soon many more of us) have been running with it as our standard development VM for a few months now. It just works.

The fact is that most programmers for the JVM will, for a long time to come, be programming in Java itself. Isn’t it time we made Java more dynamic and helped out the vast majority of people using the JVM? I’d like to think that even if it doesn’t directly affect them, that making languages more dynamic and making the world a better place even for Java programmers should be something everyone in the JVM language community could get behind.

---