This seems to be coming up more and more frequently, ColdFusion developers being asked to defend ColdFusion against a planned move to Java and J2EE. I now have three such messages in my inbox, and so I thought it worthwhile to share my response to this one.
For starters, any suggestion of “we need to stop using ColdFusion because we are going to use Java” demonstrates a complete lack of understanding of what exactly ColdFusion is. So, let’s start with a brief explanation of the ColdFusion Java relationship.
Applications written in ColdFusion (as of ColdFusion MX) are pure Java. Or, expressed slightly different, ColdFusion runs on a J2EE server (either embedded, or one of your choosing) running a Sun verified Java application (the ColdFusion engine), executing Java bytecode (compiled from your CFML source code). In other words, CFML (the code you write) is a developer-time consideration, not a run-time consideration. There is no CFML at run-time, at run-time you are executing pure Java, no more or less so than had you have written the application in straight Java. Your ColdFusion application IS a Java application, if you deploy a ColdFusion application what you have deployed is Java, it is as simple as that.
Which means that the assertion that ColdFusion and Java are somehow mutually exclusive is just flat out incorrect.
But what about the CFML code you write? Isn’t that ColdFusion specific and not pure Java? And isn’t that an issue? I don’t think so. There is an entire industry of Java add-ons out there, tools, tags, language extensions, and more, and Java shops use these (as they should, after all, why reinvent the wheel?). If your Java code leverages 3rd party add-ons for reporting, or back-end integration, or charting, or … does that make your code any less Java? Nope, not at all. Experienced developers know that starting from step one is expensive and seldom makes sense, regardless of the language and platform. Experienced developers have toolboxes at their disposal, stuff they can leverage and reuse to be as productive as possible. Experienced developers write modular applications, separating logic and processing and presentation into tiers, allowing these to evolve independent of each other, even allowing them to be inserted or removed independently. And for Java developers, one of these tools should be ColdFusion. After all, why write dozens of lines of Java code to connect to a database when a single tag can accomplish the exact same thing (likely using the same code internally)? And why write lots of code to send an SMTP message using JavaMail APIs when a single tag can do it for you (again, using those same APIs)? You can think of ColdFusion as a bunch of pre-written Java code, stuff you can use so as to hit the ground running. And that makes your app no less Java than had you had done all the work manually.
However, some may counter that CFML is proprietary, and that the fact that you need to pay for an engine to execute your code somehow makes it non-Java. I have actually heard this from customers. So, is this a valid issue? Again, I don’t think so. For starters, paid does not equal proprietary, after all, these same customers do not balk at spending big bucks on their J2EE servers (and management tools and professional services and more). Furthermore, there are indeed 3rd party CFML engines out there. I am not going to comment on how good they are and how viable an alternative they are, that is irrelevant. What is relevant is that they exist, and that means that CFML is not a single-vendor or proprietary.
Great, so, ColdFusion simplifies Java development, and ColdFusion applications are no less Java than applications written in low-level Java directly. But simplicity and abstractions require sacrificing power, right? Wrong! ColdFusion applications can (and should) leverage Java; Java APIs, Java classes, Java beans, JSP tags, you name it, ColdFusion can leverage it because ColdFusion itself is Java. It’s that simple.
So, ColdFusion or Java? The answer should be YES, ColdFusion is Java, and Java development can benefit from ColdFusion. This is not an either/or proposition, it is a “you can have it all so why the heck would you want to do it any other way?” proposition.
You can have your cake and eat it too.