But are you sure you need scripting?
People often start using JVM scripting, as I did, to accelerate the development cycle. To be able to shorten the waiting time between coding a change and being able to test that change. This waiting time, which was traditionally used to build the project and run the resulting application, tends to become a quite significant part of the code-test-code-test cycle in the later stages of a project's development, often becoming even quite larger than the coding time itself.
But tradition is not what it used to be....
From my recent experience developing Servlet based stuff with Eclipse + Tomcat, I am sure there are better ways to accelerate the development cycle than scripting. (And this does not necessarily mean that I am building a webpage per Servlet...)
Remember that Eclipse keeps (if you let it) compiling the code on the background while you do your code editing. So, switching on Servlet reloading, you can use the excellent coding productivity of Eclipse and check the result of recent changes really fast. It gets even better with smaller changes when running Tomcat from Eclipse (Sysdeo), thanks to Java's Hotswap, which Eclipse automatically uses to replace a modified class in memory and on the fly.
Moreover, when you think about it, a JVM based script (Pnuts, Rhino, whatever) compiled to memory lives in a class, which can usually be replaced in memory when the script's source file is modified. Why can't we do the same thing in Java???
Well, we can... but we have to be careful. A script can be reloaded because (or, more exactly, "when"):
- its compiled class version is only exposed to the other objects in the JVM via a well defined and stable interface;
- and the other objects always instantiate it "by name" (from the run-time / reloading mechanism), instead of holding a direct reference to the script's class instance.
In the typical worthwhile scenario where your application runs using a large stable framework that keeps calling your code (yeah, IOC, of course...), all that code of yours can be isolated with its changes managed by the framework trough the use of a custom ClassLoader.
This applies to both Web Applications (your classes might be page renderers / request handlers in a MegaServlet like Cocoon), Swing Applications (your code being form renderers / handlers, business logic), whatever. And your code can be divided in isolated - and separatedly (re)loaded - modules too.
So, for a code-test development cycle, you would star your application in "reload-changes" mode and keep editing your reloadable Java stuff with Eclipse. Eclipse just had to be set to output the compiled code to the application's reloadable classes directory.
Ok, you can not use this technique for everything, but one thing is for sure:
- If you can do it with JVM Scripting, you can doit with the reloadable Java approach described here.
[Programming][Java][Scripting]
<< Home