Quite a few of our users have contributed small pieces of code that test reloading of some parts of Java classes. Some of them have discovered genuine bugs and we are working on fixing them. However there was also some confusion that we want to clear up.

If you want to write a small test for JavaRebel you have to be aware of the two following things:

• JavaRebel will not reload code of currently running method. All new invocations of the method (even concurrent ones) will get reloaded, but the code in a running method will not reload. This means that if you have a method with while (true) {/*body*/} the body will never reload since you never leave the method. This is not a restriction in any real application, but this does show up in the small tests.
• The second issue is more particular to JavaRebel — if all running methods are of the same class they might not get reloaded (this does not always apply, but may compromise your test). This issue may come if you have only one class (e.g. Main) and try to change a method inside the same class.

The recommended way to test JavaRebel is to make a separate Launcher class with a while loop and call a method test() in another class (e.g. Test) with it. If you want to test concurrency make a separate class for threads (inner or anonymous will be enough).

JavaRebel reloads changes to Java classes on-the-fly without redeploy or restart including new methods and fields. It is a generic solution that works for standalone Java applications as well as application servers. For the impatient: watch the demonstration screencast (~5 mins) and download!

Ever since HotSwap support has been introduced in Java 1.4 people have been craving for more. As witnessed by this bug in the Sun database and numerous other discussions changing method bodies was just not enough. Dynamic languages like Ruby were quick enough to capitalize on this lacking touting Java EE development as slow and cumbersome.

As time passed by people have tried to work around the limitation by reloading classes along with their classloader. However since this requires also to reconstruct the object state it will only work in a controlled and limited environment — e.g. that of a web framework like RIFE, Tapestry 5 and so on.

Just as many others we were working on a workaround. However instead of limiting ourselves to the facilities provided by the Java platform we devised a whole new approach. Using bytecode modification and a little bit of magic JavaRebel extends the JVM with ability to reload almost arbitrary changes to classes on-the-fly. This includes adding and removing both methods and fields and the only forbidden changes are to ‘extends’ and ‘implements’ clauses. Since all the existing object instances are preserved the application and server can continue running and code changes are immediately visible in the application.

Watch the demonstration screencast (~5 mins), read the feature list or just download JavaRebel from ZeroTurnaround.com and give it a try. Disclaimer: JavaRebel is commercial software with a free trial for 14 days and developer seat cost at 99$.

ZeroTurnaround is a spinoff of Webmedia, Ltd. that focuses on Java developer productivity tools. Currently we are developing JavaRebel, a generic Java class reloader, and JSP Weaver, an instant JSP interpreter.