JavaLoader 1.0 Alpha is Released!

JavaLoader
1.0 is a project I've been talking about off and on for the past 6
months or so, and I'm very happy to announce that a release version is
now complete.

There are several key new features to JavaLoader 1.0,

Dynamic Compilation

Now
if you are working with JavaLoader, you don't have to bundle your Java
code into a jar to load.  You can simply specify to JavaLoader which
directories are your source directories, and JavaLoader will compile
and load them on the fly for you!  JavaLoader will also check to see if
your source code has changed, and re-compile it as necessary! 

For
example, if I wanted to compile and load a HelloWorld.java (that has a
simple 'Hello World' method) in my ./src directory, I could do:


javaloader = createObject("component", "javaloader.JavaLoader").init(sourceDirectories=[expandPath('./src')]);


And then create my HelloWord object as per normal:


<cfset helloWorld = javaloader.create("HelloWorld").init()>
<cfoutput>#helloWorld.hello()#</cfoutput>


No more ANT tasks, no more export to .jars, JavaLoader handles the compilation and deployment of your Java code for you.

ColdFusion Component Dynamic Proxy

For those of you who are not aware of what a Dynamic Proxy
in Java is, it is essentially an Object that can mimic an object that
implements a given set of Interfaces.  The method invocations against
that object are intercepted, and you can essentially do whatever you
like with them.

In JavaLoader 1.0, I've written a Dynamic Proxy that you are able to wrap around a CFC, and thereby make Java Objects think
they are interacting with a native Java object, but are in fact,
talking to your CFC.  When a Java Object calls a method on the Dynamic
Proxy, it is passed through and invoke directly on the CFC transparent
to your Java layer.

For example, the java.lang.Thread Java object can take an instance of the interface java.lang.Runnable in its constructor argument.  Using JavaLoader's Dynamic Proxy, we can pass it what it thinks is an instance of the Runnable Interface, but is in actuality a ColdFusion Component like so:


//give us access to the CFCDynamicProxy
CFCDynamicProxy = javaloaderloader.create("com.compoundtheory.coldfusion.cfc.CFCDynamicProxy");

//create my Runner CFC
myRunner = createObject("component", "MyRunner").init();

//wrap it in a Dynamic Proxy, that implements Runnable
runnerProxy = CFCDynamicProxy.createInstance(myRunner, ["java.lang.Runnable"]);

//pass it to the Thread and call run()
thread = createObject("java", "java.lang.Thread").init(runnerProxy);
thread.run();


…and suddenly we have true seamless communication from Java to ColdFusion components.

This
is actually something I wish I had written three years ago.  It would
have radically altered how I would have written a lot of software.

Spring Integration

A natural progression from the Dynamic Proxy, was to implement a Custom Schema in Spring, so that you could instantiate and dependency inject your ColdFusion components with your Java Objects inside Spring itself.

Initialising
Spring with JavaLoader is covered in the documentation, but to give you
a quick taste, once we have Spring running, we can include a CFC in our
spring.xml with:


<coldfusion:cfc id="message"
        script-source="file://home/www/model/Message.cfc"
        script-interfaces="com.IMessage"
        />


Where script-source is the absolute path to the CFC you want to instantiate, and script-interfaces are the Java interfaces that your dynamic proxy will implement, and your CFC has mirrored inside it.

This
Component then gets treated like a normal Spring bean, so it can be
autowired, injected, aop'd and all the usual functionality that a
Spring bean has access to.

There are some downsides to implementing Components inside Spring, so be sure to check out the documentation for more details.

Read More

For more details, have a read of the extended documentation, and have a look at the examples provided in the download.

Since
this has become a far larger project than its original inception, I've
done away with the Riaforge Forum, and have started a new javaloader-dev google group for support and discussion of JavaLoader and Java and ColdFusion integration.

While
I'm very confident in the code that I have written for JavaLoader 1.0,
I decided to call it an Alpha, simply because it has only really been
tested by me and my Unit Tests.  Knowing from experience that users of
Open Source Software have a tendency to use and abuse libraries far
above and beyond what the author had ever originally dreamed led me to
decide to call it Alpha until the community has really had a good
change to play with it.

Please download JavaLoader 1.0, take it for a spin, sign up for the mailing list, and if you find any problems please do let me know.

Leave a Comment

Comments

  • mitch rose | August 31, 2009

    congratulations mark! can’t say when i’ll need it but this is a terrific step!

  • Tom de Manincor | August 31, 2009

    Wow!

    This is one of my favorites.

    You’ve managed to continue to shrink the gap between cf and java.

    Like you said, this will alter they way I architect future projects.

    Have you had a chance or planning on providing any benchmarks on Adobe CF8/9 and Railo?