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.
Defending ColdFusion Against Java
23 responses to “Defending ColdFusion Against Java”
-
Hi Ben,
you wrote :
<< Furthermore, there are indeed 3rd party CFML engines out there….>>
Just for curiosity could you give me some links to these 3rd party CFML engines ? I did not know anybody,
thanks a lot -
BlueDragon by New Atlanta is the best known, there are others too.
-
That was a perfect explanation!
Thanks!
I can use this when speaking with my prospective clients.
Great job Ben!
Thom -
this article (http://www.sys-con.com/coldfusion/article.cfm?id=532) could add a little more for those still confounded by the cf/java mix… and another engine you could check out, apart from bluedragon, is ralio
-
Excellent response Ben! I’ll be sure to add this blog to my arsenal. It’s so funny when people mention how ColdFusion is so proprietary yet turn around and buy a "proprietary" vendors implementation of Java (WebSphere, BEA, etc.). For those facing the J2EE vs ColdFusion debate at work, try offering to perform a simple demonstration and code comparison. I’m sure they’ll appreciate the idea of shorter development times with ColdFusion apps. I’ve developed in JSTL, Struts, PHP,and ASP.NET C#. However, I LOVE Coldfusion (MX+ though).
-
> You can have your cake and eat it too.
There is no need at all to educate/convince any CF developer on the benefits of CF. Touch it. Love it. The real issue is we are living in a world of open source, free software and cost-conscious customers. In this world it will be harder and harder to make customers eat the cake too. In general programming languages are "free". PHP, ASP.NET, C# developers can develop an application and set a competitive pricetag. Developers using Macromedia programming languages (CFML, MXML) can’t do this. They are constrained by the high price of the required servers to make their application run. This is the real issue Macromedia developers are facing. They know how to make the cake and eat it, but want Macromedia to offer the ingredients at a price they can sell the cake too. Pointing to a supplier who delivers second class ingredients is not an option. -
it was from Robin Hilliard’s lips (then MM australia) that perhaps summed it up best for me:
"CF is the fastest way to write java web apps"
taking into account the points you mentioned, means that CF is (thanx to being an untyped language, etc) a "macro-type" (or perhaps a 4GL) language to write Java.
In that context, CF could be seen as a Java RAD tool… (which is both insult and complement)
just my 2c -
Nice try, but for organizations that want their programmers to be able to work in both console apps and web apps so that they can help out in programming sprints, ColdFusion is not Java. Sure, it produces Java code, but a ColdFusion programmer can’t take their code skills and build a Windows application, nor can a Java person take their skills and build a ColdFusion site.
I say this because this is exactly the situation our company is in: we have an established base of Windows applications written in Java that we’ll need to maintain for the foreseeable future. The attraction to using J2EE as a web tool (but not ColdFusion) is that we can hire J2EE web guys who will also be able to contribute to code sprints for the Windows apps when necessary. Sure, you don’t want them doing the architecture, but if you need help with some short modules, they can contribute – whereas CF guys would be much less useful. -
depends who your CF "guys" are. Not every CF programmer is some ex-html designer, and plenty of us have a formal software education (I write CF 90% of the day, but wouldn’t balk at working on a windows/unix app written in C, C++, C#, OR Java).
-
Brent O. comments above are based on the assumption that ColdFusion developers are mono-talented, that they know nothing else except ColdFusion. I don’t think that there are successful CF guys who don’t know some other languages or technologies. In fact many come to CF from other backgrounds like ASP, PHP, and, heaven forbid, Java! When the need arises, a good CF developer will reach out to whatever tools can be used to solve a particular problem or to provide an elegant solution that CF cannot offer. Because CF is such a good RAD environment, it saves a lot of development time and will allow the developer plenty of opportunities to explore alternatives solutions or, more importantly, to get to learn the business end of an application so that what is created in CF closely tailor the real world’s needs and desires. That, in my humble opinion, is what really sells CF: its nimbleness and adaptability to many business situations.
-
Brent, others have already commented, but I’ll ad one more point …
Java developers can write really good CFML if needed. Some of the best CF code I have seen is code written by experienced Java developers who applied that experience to CF and ended up with the best of all worlds.
Sure, if all a developer knows is CF than they will have a learning curve to deal with to get to Java. Java developers have them same learning curve, they have just started at that end of the spectrum. -
Hmmm. I dunno, CF apps are a set of loosely coupled pages that are individually compiled at runtime. Java apps are structured, strongly type-casted collection of classes that are compiled at compile-time. That structure is what many developers say makes Java apps faster to develop and maintain once they get larger.
CF and Java – which is easier?
Putting things in perspective, when all you want to know is today’s date you obviously don’t want to fool around with instantiating a date object. However at some point you’re likely going to want to do more with today’s date that just display it on screen and having that reusable date object instead of a date-formatted string makes life much easier for you later.
In other words, the Java language’s complexity is just a reflection of how complex today’s business problems are. It was designed to meet just about every problem head on and the fact that is used everywhere from servers to cell phones is a testament to that.
So is CF the same as Java?
Well… you can leverage Java from CF but making the two shake hands in some areas like data type conversions (Java is strongly typed whereas CF is not) exposes the less-trivial reality of the situation. CF-only developers (and no, not all CF developers are monoglots) cannot fully benefit from Java so it is more appropriate to say that CF can be Java if the developer knows his or her Java well enough. CF abstracts the complexities of Java that also give you power. Leveraging APIs is one thing but benefiting from the semantics and structure that Java uses to combat business problems requires more than CF asks of a developer.
After-thoughts
It would’ve been nice if this blog entry acknowledged methods of manipulating DBs aside from "the dozens of lines of JDBC code" (worst case scenario in Java). It is now possible to manipulate databases without any SQL code at all thanks to ORMs like Hibernate. And even if you can’t figure out Hibernate there’s SQL tags that are virtual copycats of CFQUERY at one’s disposal. This used to be one area where CF had a leg up on all the competitors but I’d say that JSP and CF are on fairly equal footing now. -
Ben,
Would you be able to convince SUN microsystems to run Cold Fusion MX on Solaris and Sun One server, and if so what would be your arguments for doing so… keeping in mind that they already have all of their systems up and running and we would be a new developer stepping in to develop applications on their platform.
Any help appreciated… -
Gavin, sure, and the value proposition would be essentially what I outlined in this entry. Sun ONE provides the infrastructure, and CF makes that infrastructure insanely simple to leverage.
-
thanks
-
"…why write dozens of lines of Java code to connect to a database when a single tag can accomplish the exact same thing… why write lots of code to send an SMTP message using JavaMail APIs when a single tag can do it for you… that makes your app no less Java…"
It may make your app no less java, but I also think it makes your app much less structured, and much less architecturally appealing. Most of the app designers I know believe MVC is a very important strategy (Model, View, and Controller should all be clearly separated). It seems to me that CF munges them all together (but I’ve admittedly never written in CF). In my opinion, that makes an app much more difficult to mantain and to reuse.
For quick and simple apps, prototypes, or proof of concept apps, it sounds like CF is an *excellent* way to go. But for long-lasting, highly scalable, enterprise applications, I’m still gonna put my money on Java. -
Chris,
You are mostly correct. The problem with CF is that it’s so damn easy
to use that people who don’t have a lot of development experience (or
those that never learned "best practice") end up generating a lot of
spaghetti code, which is not maintable and ends up giving CF a bad
rep.
The truth is, however, that CF provides facilities to implement design
patterns (like MVC) with relative ease, and you *can* build highly
scalable, enterprise applications with CF. Take a look at Mach-ii, a
CF application framework that fully implements the MVC design pattern.
Lastly, there are situations where CF is not up to the task, however
you usually can dip down into java to accomplish that last 10-15%, and
integrate that with your CF project without hassle.
-Dave -
So to clarify, Cold Fusion is a powerful tool that writes java code for you, saving time. As any experienced programmer knows, that is great as long as you COULD go in and over ride the "generated code" if you had to. It seems that it would be advisable for all CF developers to become as familiar with JAVA as possible, then just use CF as a convenience. It would NOT be advisable to start with CF and never learn Java, or you will likely create messes for yourself that you cant clean up.
-
I know this topic is slightly outdated, but for those arguing about MVC in CF. Fusebox, Mach-II, ModelGlue are SOME of the frameworks that exist for coldfusion.
-
I think MVC is exceedingly important, but you should try telling that to a developer who has been with ColdFusion for earlier releases. Try telling them to break away from the spaghetti code mentality. I can’t tell you how many eyes were rolled at the 04 Macromedia conference when the first round of best practices were preached (By Ben, i might add). As someone who started in the CF world, I can tell you that Java has offered us more stability, scalabilty, and most importantly (to me) consistency and maintainability. RE: CF scalability, has anyone even tried persisting CF objects in a clustered environment? Good luck trying!
-
Jenn B.: By using client variables instead of session variables, you can easily persist variables across servers in a cluster. WDDX packets serve as the means of passing complex variables back and forth to the persistence layer, and all the plumbing can be encapsulated in utility CFCs. For example, we use an ISession.cfc as an interface extended by a SessionManagement.cfc and a ClientManagement.cfc, which allows the developer to use the same getters and setters regardless of whether or not client vars are used in place of session vars. We achieve seamless persistence across 4 or 5 clustered servers with the added benefit of no longer having broken sessions in cases of dynamic IP-assignment (which AOL does for its users, for example). This is all without even using JSessionIDs, which allow for true J2EE cross-server *and* cross-cluster session persistence.
As for the spaggheti code issue, I think it’s been pointed out here already that the fault there is primarily with the coder, not the language. All of our coders have been quick to adopt Fusebox, which gets away from most dangers of procedural garbage while also preparing them to move into OO as projects demand. Meanwhile, I have to agree with the earlier post that good coders are good because of their broad-based experience, and that the best CFers have other experience in their background (Java, VB, C#, whatever).
Just some thoughts … -
I agree that cf is essentially java.
It is possible to decompile all of cold fusion’s source code 😉
I went about writing cf code that calls a decompiler to inturn convert a directory(s) of cfm/cfc files into java source code. This is an excellent learning tool for understand java and the transition of cf to java.
If you ever wanted to learn what happends under the hood of cf, or if you wanted to use cf as a reference to learning java then this is a great approach. And once again demonstrates that cf is an api that leverages java.
Theo -
I am an experienced programmer and have been using Python scripting quite a bit. I trained many people at my organization in Python. I was looking to expand my competencies, so I purchased the cold fusion manual and downloaded the trial version. I enjoyed the approach that CF takes. I found it to be Python like. What I mean by that, the programming is script like. I did find that I needed a bit more understanding of web programming, so I took a web development course at Brandeis. This was all XML and Java Based. By the end of the 12 weeks I had worked my way through XML, CSS, servlets, JSP, Struts and on to JSF.
My take away from the course, was an understanding and appreciation for XML. CSS, but I did not really get Struts and JSF.
My question is this.- Can’t you do most everything in CF that Struts and JSF tries to do. At least with CF there is a migration path. What do you do with your CSF code when the next greatest Java framework is released, start all over again.
Leave a Reply