JavaLoader.cfc v0.1 Released (Loading Java from ColdFusion part 2)

Well, I *was* going to go to the gym, but noooo, I got pestered by a bunch of people to actually produce a generic version of my JavaLoader that I talked about in a previous blog post .  You people know who you are, and you should be ashamed.  Ashamed that you forced me to produce more open source code. Shame on you indeed.

Now that I've got all that drivel out, I've released a generic version of the Java Class loader for loading external JAR files.  Be they ones you created, an open source library, or a library you created to work with *another* jar library – all is possible with this tool.

The key features of this CFC are:

  • It can load several libraries at once, thereby allowing linking between Java libraries
  • It allows access to ColdFusion core Java files, as well as the Java libraries that are loading with ColdFusion
  • It utilises the coldfusion.runtime.java.JavaProxy, which enables ColdFusion to do Object constructor arguments as you would normally with createObject("java", "javaObject").init(myArg);, as well as being able to give access to static fields on Java objects that cannot be instantiated.

So, how do we use it? Well, there is an example in the download , but I'll give you a run down here.

Say we have a jar file, 'toolbox.jar', and we went and wrote our own code base and stored that in 'ourcode.jar' that referenced objects in toolbox.jar.

First we need to create an Array with the absolute file paths to each of these in it, so we would go:

paths = ArrayNew(1);
paths[1] = expandPath("toolbox.jar");
paths[2] = expandPath("ourcode.jar");

Then we create our JavaLoader, passing in the array, so it knows what to load –

loader = createObject("component", "JavaLoader").init(paths);

So now, we can create a instance of an object from ourcode.jar, say, for example the 'OurCode' class

If we were to just want to create a default (no arguments) instance of OurCode, we could now go:

ourcode = loader.create("OurCode").init();

Just like we would on a createObject("java", "OurCode").init() call, if we had access to the 'OurCode' class.

But say, for example, OurCode also had the option of taking an int and a String as an argument – we could now go:

ourcode = loader.create("OurCode").init(15, "I love Strings");

Again, same as we would on a createObject("java", "OurCode").init(15, "I love Strings") call, if we had access to the 'OurCode' class.

But what if we wanted to get complicated, I mean, we said that ourcode.jar referenced code in toolbox.jar, so maybe OurCode may want to take a ToolBox class instance as an argument – this is all possible.  We have loaded both JARs into the loader, so we can get to both instances, and we use CF to make the constructor work, like so:

toolbox = loader.create("ToolBox").init();
ourcode = loader.create("OurCode").init(toolbox);
 

Again, same as we would on a createObject("java", "OurCode").init(toolbox) call, if we had access to the 'OurCode', 'ToolBox' classes.

Oh, and I almost forgot, what if we want to access static methods, or values? Still the same thing as createObject – we just don't call an init() on the object we get on the create() call, like so –

Utils = loader.create("Utils");
resultFromStaticMethod = Utils.doThisThing("hello");

Again, same as we would on a createObject("java", "Utils") call, if we had access to the 'Utils' class.

That is actually it, in terms of using the JavaLoader, but this opens up a huge area of development where in theory you could actually write most of your object development in Java, and then just have the display tier in CF (I'm not advocating the idea, but you *could* do it), not to mention you now have access to almost every Java lib out there that doesn't require you to install anything J2EE, like a servlet etc – which is a very powerful thing.

Hope you all enjoy. Any questions or comments, either send me an email , or respond to the blog post. 

Details on the project can be found here.  

Leave a Comment

Comments

  • Mike Kelp | May 12, 2006

    Brilliant! I think this would solve several problems with issues I’ve had in shared host environments. As you can imagine, they are not so willing to spend their day adding java libraries to the class path for all the clients on one box.

    Great work and sorry you didn’t go to the gym. Eat a cookie…it will make you feel better.

  • Steve House | May 12, 2006

    Wow this it nice! Just so I am clear, this is an alternative to adding your JAR files to the lib folder, correct?

    Don’t worry I’ll do 100 crunches for you.

  • Mark | May 13, 2006

    Steve,

    This is an alternative if putting JAR files in your lib isn’t an option for you – i.e. shared hosting, or if you haven’t got control of the server.

    There are a few other reasons you want to use this approach rather than loading the JAR files with CF at loadtime – like organisation etc, but that boils down to personal preference.

  • Murray Hopkins | June 7, 2006

    Hi,

    I just wanted to say thank you. Tonight I went from knowing very little about java to writing my first "do nothing" java app and getting CF to run it!! Bloody beudy ! (yes, I am an Australian).

    I wanted to do all this because I have some complex CFScript that runs very slowly (and in a hosted environment) and I wanted to experiment with writing it in java to see if it is faster. So here I am. Thanks to you and your friends I can give it a go.

    Cheers,
    Murray