Java class file reloading in Field

One very common mode of operation for Field is to use it in conjunction with your favorite Java development environment: say, Eclipse on one screen, Field on another. The idea is that you use a big serious environment like Eclipse for your big serious pieces of Java and then test, explore and stitch them together using small amounts of code written in Field.

Up until now, this has worked best if these two phases of development — writing Java, and working in Field — don't overlap so much. Because every time you change a Java class, you need to restart Field to see the changes.

Well, no more! Field's ReloadPlugin allows you, under certain circumstances, to reload classes into Field on the fly — no restart required.

The problem

Let's go through an example. Pretend that we have a new project in Eclipse:

First, we remember to tell Field where Eclipse puts the classes for this project. Right click in the plugin manager and "Add Directory/Jar to class path" (click to enlarge)

Now (after a restart) Field can see the classes made by this Eclipse project:

Give this Java source code in Eclipse:

If we change this Java source to

...
    public String hello = "goodbye";
...

And recompile in Eclipse, Field knows nothing about this change! Until we restart. If this was a complex piece of code that we were testing in Field then we might end up restarting Field an awful lot.

The Reload Plugin

Classfile reloading in Java generally falls into the category of "deep magic" — the JVM hasn't really been architected with this feature in mind. Field's reload plugin gives you an 80% solution with the minimum of fuss.

With the plugin activated you'll see a new tab in the top left of the screen:

This plugin keeps track of all classes loaded by Field, for whatever reason — your classes, and classes in subsidiary .jars that your code might call upon — and displays them in a hierarchy.

Right clicking on any art of the hierarchy — package or class — allows you to install a "class reloading domain" at that point.

And, yes, you'll have to restart one last time to make these classes reloadable. Upon restart (and rerunning the code you have that loads the classes), you'll see a new entry in that list the represents that package / class. To reload it, right click on it (or just double click)

Limitations / What's actually happening

As with all Class file reloading strategies there are limitations — to take full advantage of Field's reload plugin you might end up structuring your projects a little differently. Here's the main limitation:

1. Putting a class inside a "reloading domain" makes it invisible to classes inside other domains. That class can see all other classes inside its domain and not otherwise marked as reloadable.

This means that you'll want to structure your code so that packages are relatively independant during the kinds of rapid fire testing that typically gets you into endless cycles of restarting Field.

The second limitation is less onerous:

2. The python import statement should only be executed once, not every time you reload.

The python import statement will go fetch the old version of a class, this is very unexpected. The solution, put your import statements in a separate box and you wont end up executing them by accident.

Finally, and this really goes hand in hand with 1:

3. You'll need to reinstantiate your reloaded classes.

Field doesn't patch existing instances. It doesn't seem possible to do this without causes broad slowdowns in the VM even in the non-reloaded case. Again, keep your classes loosely coupled (and easily recoupled) while testing. Like '1' above this is just good discipline.