JavaScript ClassLoader and Hotspot

If you are familiar with Java debugging, you must know there is a technology called “Hotspot“. One feature of Hotspot is to replace old classes bytecodes with a new ones that are generated by dynamic compilers. This feature helps developers a lot in debugging. That is to say, when a developer load a very complex application in debugging mode, he want to modify the sources a little, he can just do it, the compiler will compile those related classes and notify classloader to load those affected classes bytecodes. And the modified codes are on effects. It saves lots of time by avoiding closing, reopening and waiting big applications again and again. This is very convenient when comparing to those static compiled applications written by C or C++ languages.

OK, now comes to JavaScript classloader and Hotspot technologies. JavaScript classloader technology are already proved by Java2Script. You can load JavaScript classes on demands, and using SCRIPT in asynchronous mode or XMLHttpRequest (XHR) in synchronous or asynchronous modes. And these days, Java2Script is also implementing JavaScript’s Hotspot technology (Not released publicly at the time of this writing, but you can check Java2Script out from SVN repository right now using its 3.3 compiler branch.). Such JavaScript Hotspot technology is not complicate, because JavaScript is already a very robust and convenient language to do so. All Java2Script implementation is to clean those classes’ declaration inside JavaScript class inheritance system simulator. And then reload the *.js using Java2Script’s classloader. In the implementation, classloader does not change class or object’s prototype when a reloaded class is redefined, it’s possible to keep all classes relationships without breaking those already instantiated instances.

To trigger Java2Script class simulator to Hotspot swapping, there is a thread trying to load an updating JavaScript classes list from Java2Script compiler in Eclipse. Its work is simple, just trying to load http://127.0.0.1:1725/<session>.js. And the server listening on default port 1725 is started by Java2Script compiler, called “Java2Script Inner Hotspot Server (J2SIHS)”. When a compiling occurs, compiler will notify this server that a class is updated, and the server will add the information to the list. Once a JavaScript request arrives, it will send out the list according to the request session id. And when the JavaScript client thread gets the updated classes list, it will try to unload related classes and reload them. That is the rough procedure of Java2Script Hotspot technology.

By using Hotspot, I think it is much more convenient for me to develop JavaScript RIA in Java codes than before, especially in developing SWT applications.

This entry was posted in Architecture. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *