Featured White Papers

• Utilizing Fast Testing to Transform Java Development
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Add dynamic Java code to your application

Write code that can respond to changes at runtime

By Li Yang, JavaWorld.com, 06/12/06

Page 3 of 5

Detecting file changes can be achieved by comparing modification timestamps and file sizes. For our example, a check to PostmanImpl.java is performed every time a method is invoked on the Postman interface. Alternatively, you may spawn a daemon thread in the background to regularly check the file changes. That may result in better performance for large-scale applications.

Compile Java code at runtime

After a source code change is detected, we come to the compilation issue. By delegating the real job to an existing Java compiler, runtime compilation can be a piece of cake. Many Java compilers are available for use, but in this article, we use the Javac compiler included in Sun's Java Platform, Standard Edition (Java SE is Sun's new name for J2SE).

At the minimum, you can compile a Java file with just one statement, providing that the tools.jar, which contains the Javac compiler, is on the classpath (you can find the tools.jar under <JDK_HOME>/lib/):

   int errorCode = com.sun.tools.javac.Main.compile(new String[] {
            "-classpath", "bin",
            "-d", "/temp/dynacode_classes",
            "dynacode/sample/PostmanImpl.java" });

The class com.sun.tools.javac.Main is the programming interface of the Javac compiler. It provides static methods to compile Java source files. Executing the above statement has the same effect as running javac from the command line with the same arguments. It compiles the source file dynacode/sample/PostmanImpl.java using the specified classpath bin and outputs its class file to the destination directory /temp/dynacode_classes. An integer returns as the error code. Zero means success; any other number indicates something has gone wrong.

The com.sun.tools.javac.Main class also provides another compile() method that accepts an additional PrintWriter parameter, as shown in the code below. Detailed error messages will be written to the PrintWriter if compilation fails.

   // Defined in com.sun.tools.javac.Main
    public static int compile(String[] args);
    public static int compile(String[] args, PrintWriter out);

I assume most developers are familiar with the Javac compiler, so I'll stop here. For more information about how to use the compiler, please refer to Resources.

Load/reload Java class at runtime

The compiled class must be loaded before it takes effect. Java is flexible about class loading. It defines a comprehensive class-loading mechanism and provides several implementations of classloaders. (For more information on class loading, see Resources.)

The sample code below shows how to load and reload a class. The basic idea is to load the dynamic class using our own URLClassLoader. Whenever the source file is changed and recompiled, we discard the old class (for garbage collection later) and create a new URLClassLoader to load the class again.

 // The dir contains the compiled classes.
    File classesDir = new File("/temp/dynacode_classes/");





    // The parent classloader
    ClassLoader parentLoader = Postman.class.getClassLoader();


    // Load class "sample.PostmanImpl" with our own classloader.
    URLClassLoader loader1 = new URLClassLoader(
            new URL[] { classesDir.toURL() }, parentLoader);
    Class cls1 = loader1.loadClass("sample.PostmanImpl");
    Postman postman1 = (Postman) cls1.newInstance();


    /*
     * Invoke on postman1 ...
     * Then PostmanImpl.java is modified and recompiled.
     */


    // Reload class "sample.PostmanImpl" with a new classloader.
    URLClassLoader loader2 = new URLClassLoader(
            new URL[] { classesDir.toURL() }, parentLoader);
    Class cls2 = loader2.loadClass("sample.PostmanImpl");
    Postman postman2 = (Postman) cls2.newInstance();


    /*
     * Work with postman2 from now on ...
     * Don't worry about loader1, cls1, and postman1
     * they will be garbage collected automatically.
     */

Pay attention to the parentLoader when creating your own classloader. Basically, the rule is that the parent classloader must provide all the dependencies the child classloader requires. So in the sample code, the dynamic class PostmanImpl depends on the interface Postman; that's why we use Postman's classloader as the parent classloader.