If you use ColdFusion (or another Java-based CFML runtime), you should be using Java. There's a reason that CF uses Java under the hood: Java is incredibly powerful. Yes the interface to Java from the CF level is cumbersome and creating hybrid CF/Java applications pretty much costs you CF's RAD capabilities, but there are some real gems in the Java libraries.
On CF-Talk today, someone asked about reversing an array. There's not a built-in function for doing that, but if you remember that CF arrays are just Java Lists (java.util.Vector, specifically), you can suddenly leverage the full Java Collections framework. In this case, the solution was simple:
createObject("java", "java.util.Collections").reverse(myArray);
Want get unique values from an array? Not a difficult problem, but how about this:
myArray = createObject("java", "java.util.ArrayList").init(
createObject("java", "java.util.HashSet").init(myArray)
);
Want them sorted? Here you go:
createObject("java", "java.util.Collections").sort(myArray);
Yes, there is an arraySort() CF built-in, but it only sorts text and numbers. So if you want to sort an array of Dates, you're stuck. Collections.sort, on the other hand, will happily sort the dates.
This only breaks the surface of what you can do with Java. Obviously you can't leverage this if you have to support non-Java CFML runtimes, but if you developing for a Java runtime (or runtimes), you owe it to yourself to learn a little bit about the Java tooling available to you. I've blogged about a couple other Java tricks (fast directory filename listings and string builder tricks) in addition to myriad Java libraries that can be leveraged (Batik, Weka, Ant, etc.)
Here's an complete example of the above tricks:
a = [1, 2, 3, 4, 5, 1, 2, 3, 4, 5];
// reverse it
createObject("java", "java.util.Collections").reverse(a);
writeOutput(a.toString()); // [5, 4, 3, 2, 1, 5, 4, 3, 2, 1]
// sort it
createObject("java", "java.util.Collections").sort(a);
writeOutput(a.toString()); // [1, 1, 2, 2, 3, 3, 4, 4, 5, 5]
// pull unique elements
a = createObject("java", "java.util.ArrayList").init(
createObject("java", "java.util.HashSet").init(a)
);
writeOutput(a.toString()); // [3, 2, 1, 5, 4]
// unique elements in sorted order
createObject("java", "java.util.Collections").sort(a);
writeOutput(a.toString()); // [1, 2, 3, 4, 5]
Praise be to Java regular expressions!
OP here. Thanks for answering my question on HoF Barney. To be fair to myself, I did try the following:
1) ColdFusion's Reverse() method. Doesn't work on arrays.
2) Searched for a built in method for ArrayReverse. None found.
3) Searched the Java docs for an array reverse method. Couldn't find one.
4) Posted to the HoF list.
I knew one of my colleagues had an answer for, and it doesn't surprise me that it was you. Thanks again.
Awesome, simply awesome blog post!
I've been doing CF for quite a while now, but I can't get over how extensive and powerful the Java API is–doubters are welcome to go look at the API and come back when they're through.
As you say, your examples only scratch the surface, but the more time I spend with Java, the more I realize that until now I've really just been using relatively primitive tools for programming. That isn't to say there's not a place for CF, but the more I learn about computers and programming, the more obvious its limitations become.
Jason Delmore did a talk at CF.Objective() about CF Java integration, I missed it myself (although I did see some of his slides, discuss it with him and heard a lot about it from others), but I hear there were lots of similar tips there. So if anyone is interested in finding out more about using Java within CF, you may want to hunt down that presentation.
To add to that, there has been a lot of buzz in the community from many influential developers begging for (demanding?) ActionScript on the server. The viability of such an implementation has many challenges, but it sort of led me and others to suggest that if you really want that type of syntax, just write Java! Don't get me wrong, I love AS3, and if there was a way to use it with CF, I would. But before you knock down Adobe's doors trying to get it, you may want to take another look at your Java options.
Barney,
Wow! I went to cf.Objective() last week and listened to some of the "great ones" speak on integrating Java (and ActionScript) with ColdFusion and I have to admit that I was REALLY intimidate by the fact that I only understood about every third word that was spoken.
Your blog post has opened my eyes to just how simple it can be to use some of these little, yet powerful, features. It inspires me to want to learn more about Java instead of feeling the overwhelming urge to curl up in a corner and pray that my development career will not die because I WAS afraid of Java. Thanks!
Now I just need some free time to learn more.
@Rachel: The problem with that line of thought is that if you go that route and start writing your Model in Java, you essentially lose all the other great easy to use services that CF gives you. It's pretty much all or nothing. I know there are some ways to get around that with varying degrees of success (like the CFC Proxy for Java) but they all have serious drawbacks. On the other hand, actually writing any significant Java code within CFML is also infeasible and verbose. Not to mention the JavaCasts that would have to overrun your code. If the Adobe folks could deal with some of these issues (either with Java or with AS3) I think a lot of people would be really happy. That's at the core of what people are begging for. I have a blog entry on the same topic at http://www.briankotek.com/blog/index.cfm/2008/5/6/cfObjective-2008-and-the-Future-of-ColdFusion which is getting a lot of comments and as one might expect, the idea evokes a wide range of responses.
Very interesting, thanks for blogging about it. Someone should write a book on all of the untapped functions of Java and how they can be used in exactly the same sort of examples you've given, Barney.
People don't need to know Java to lift aloft their mighty sword and call upon the power of Greyskull, just a cheat sheet of of Java function names and what the parameters are. Thanks for the revelation. :-)
[...] http://www.barneyb.com/barneyblog/2008/05/08/use-coldfusion-use-java/ : il est question ici d'utiliser toutes les fonctione de java à partir de coldfusion. Par exemple, en coldfusion, vous ne pouvez trier dans une collection que des chaines ou des nombres. Si vous vouliez trier des dates, il faudra passer par java, qui rappelons le est le fondement de coldfusion. [...]
"Yes the interface to Java from the CF level is cumbersome and creating hybrid CF/Java applications pretty much costs you CF's RAD capabilities…"
Not if you hide the Java inside UDFs.
function ArrayReverse(myArray) {
return createObject("java", "java.util.Collections").reverse(myArray);
}
@Patrick: sure that works for small, one-off uses of the underlying Java API. But doing any significant Java coding within CFML is like pulling teeth, since things like static methods or properties still require an entire CreateObject call to get at, and so does every other Java object. Add on the need to cast everything properly to be sure CF is passing the right types and it adds up to an extremely cumbersome experience. At that point you're probably better off just writing your own Java classes or wrappers and calling them. But there is no doubt that whichever way you do it, there are drawbacks and hoops to jump through.
@Brian – I sort of formed my perspective on this with the hope that the future direction of CF will position it as more of a "services" platform, and that integration with Java (or various other model tier options) will improve in the future. Maybe I'm overly optimistic :)
I see your point: while advanced developers *could* write Java – they have the skills – it's certainly not RAD, so CF has a real opportunity to become a better productivity layer for Java.
For the last couple of years I've been developing mainly hybrid CF/Java apps. Java adds a lot to CF, for instance since arrays in CF use the java.util.List class, the indexOf method is very good for returning the position of an item in an array that you're for:
<cfset foo = myArray.indexOf(variables.valueToFind)/>
This blog posting,
http://coldfused.blogspot.com/2007/01/extend-cf-native-objects-harnessing.html
gives a lot of suggestions on how to utilize java with CF.
regards,
larry
@Brian – Good point. I forget how much CF does to shield me from Java's type system.
Great article. I have been in a few environments where Coldfusion developers sat next to Java developers and no one spoke about the possibilities of leveraging service/data api's, already written in Java, by exposing the api's to Coldfusion Web applications. Why shouldn't Coldfusion Web applications reap the benefits of service/data tiers complimented by technologies like Hibernate and/or Spring? Coldfusion's Web Service integration is nice and simple, so why not just expose your Java api's? I understand that most Java shops are not going to go out and spend the $$ to bring Coldfusion in, but if you are already working with both technologies in your shop or you have some ambitious Coldfusion developers who want to learn Java, all you need to do is get to work.
The main issue is casting. CF will try to cast things if it can, but one still ends up with lots of JavaCasts in their CF code when working with Java objects.
Larry,
One thing to watch out for is indexes. CF uses one-based indexes, but Java uses zero-based indexes. So if you use the code you showed:
<cfset foo = myArray.indexOf(variables.valueToFind)/>
'foo' will be off by one if you use it in CF manipulations of the array. Not a hard problem to work around, but another one of those things that makes CF/Java more cumbersome than it ought to be.
The biggest RAD-killer for CF/Java hybrids is that if you want to write any Java, you end up adopting the JEE development model of frequent server cycles. One of CF's biggest assets (probably it's biggest) is it's automatic recompilation of code. Lose that, and CF is a LOT less useful. And with the proliferation of more native Java frameworks (like Grails), removing CF's dynamic compilation probably pushes CF from the top position in terms of developer time optimization.
Great post Barney! Jason Delmore's talk was really good – it was fairly basic and introductory but it did touch on how powerful it can be to leverage Java under the hood in similar ways to what you mention (he specifically showed the vast String API that Java offers to CFML developers). The more exposure we can get for this approach, the better IMO.