The Dopefly Tech Blog

« The Dopefly Tech Blog Main page

Where is the ColdFusion+Java application model?

posted under category: ColdFusion on June 6, 2009 by Nathan

What happened to the early days of using Java as the model for a ColdFusion-based MVC application? We used to talk all about CF w/Java but I don't hear it anymore. At best, it's rare. I like to keep my ear to the ground in the CF world, and this one has quietly slipped off the radar.

I guess there are only a few likely demises:

  1. The buzz has faded and we all forgot about it
  2. It's being used everywhere and no one talks about it anymore because it bores us
  3. Java is too hard to write for the average CF programmer
  4. The integration is too bothersome, the gain is not worth overcoming
Regardless, it probably comes down to the fact that some shops have done it, and are now quiet about it, the rest ignore it completely. So in order to spur on the conversation a little, to see what went wrong, see if it's worthwhile anymore, and dream about what it could be, let's think for a bit...

OO ruined my business
A good amout of the conversation lately has been that OO is too hard and CF's implimentation of it is too awful to use realistically. I don't actually think so, but it does limit us some. Hal Helms's main argument is that the computation costs of instantiating CFCs is too great, and I agree, it slows down after a few dozen objects, and crawls after a few thousand. Multiply times 5 if you have execution time debugging on. Obviously Java's implementation of objects doesn't have this issue, especially with POJOs, the simpler the better.

So what if the solution to Hal's problem is partially using Java? Even if it's just for those objects that we might create thousands of instances of, the improvement could be huge.

That's possible today, but it's not as simple as we need it to be.

We know that in CF, createObject("component","com.myCFC") will make ColdFusion to check a variety of locations for that object. First one it finds, wins. What if you could just create a .java or .class file and call it in the exact way you call a cfc using CF's smart path finding senses. I'm honestly surprised that we can't do this yet. For me, personally, this would quickly and easily bridge MOST of the gap.

The problem actually runs much deeper even. Say I want to use my CFCs to run queries. I don't want to hunt down JDBC drivers. I don't want to script my sql calls. I don't want to worry about a thread pool and persistent connections. I don't want to work too hard. I just want to say <cfquery>select * from my_table</cfquery> and have it work every time. CFQuery is and always has been the killer feature of ColdFusion.

So I like my data access layer in CF, but maybe I want my services or beans or what have you in Java, for speed. I want to call myService.getMyData(). The service calls a cfc to get the data, then populates a bean or returns a query or whatever. Problem is, Java can't call methods on a CFC! No, I'm not kidding. Try it. Oh, and yes, I know about the cfc gateway, an asynchronous method for Java to call CF - and no, that doesn't count. Yes it's great and powerful, but that's just not it.

So it looks like the only way to truly integrate Java into our CFC model is to either replace, package-by-package, entire areas of your model-or the entire model-, or only provide one-way objects, that is, Java objects that will never need to call a CFC or anything in CF at all.

Replacing your model is doable for some shops, especially with large Java teams, and is probably indispensable for a handful of them. For the rest of us, we just love our precious cfquery! I think the real heros in this space seem to be Barney Boisvert, who is always blogging about integration with hibernate and groovy, and Mark Mandel with his JavaLoader project.

The one-way objects may work pretty well, but then we've got the classpath and instantiation annoyance still.

The way I see it, integrating Java with your CFC back-end is broken, and it's going to take a lot of "brilliant" (yes, a dig at Adobe marketing) to make it work.

Nathan is a software developer at The Boeing Company in Charleston, SC. He is essentially a big programming nerd. Really, you could say that makes him a nerd among nerds. Aside from making software for the web, he plays with tech toys and likes to think about programming's big picture while speaking at conferences and generally impressing people with massive nerdiness and straight-faced sarcastic humor. Nathan got his programming start writing batch files in DOS. It should go without saying, but these thought and opinions have nothing to do with Boeing in any way.
This blog is also available as an RSS 2.0 feed. Click your heels together and click here to contact Nathan.