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:
- The buzz has faded and we all forgot about it
- It's being used everywhere and no one talks about it anymore because it bores us
- Java is too hard to write for the average CF programmer
- The integration is too bothersome, the gain is not worth overcoming
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.