I started working for msg at.NET and my first task was to rewrite an old ColdFusion application using the Mach II Framework. This was mainly done for comparison reasons, to see if it would pay off doing projects with Mach II. Because I am a little bit into Java, and Java is definitely my favourite programming language so far, I offered expand the little research and compare these two ColdFusion applications with a Java solution. The Java solution was programmed using the Spring Framework, a light-weight Java container.
Download the application for ColdFusion and Java (note that this is not the original program I had to convert but a simpler one).
The first thing I encountered was that writing an application in Java is as easy as writing it in ColdFusion. So there is no difference in that spectrum. This is at least true for someone that knows some basics about Object-Oriented Programming.
When comparing the two solution directly there is no question that the application written in Java is more flexible and easier to maintain. This is achieved due to the use of Java’s great language features like interfaces, abstract classes and type checking combined with good practices like inversion of control.
It is no problem to switch from one database to another or even change the database type. These changes have no effect on the underlying code. These capabilites also make testing easier. You can easily write stub implementations or mocks to test the application without the need to set up a database.
The changes can be made without redeploying the whole application. All important settings can be done declaratively in xml files.
As you can see there are nearly no restrictions or functionalities missing what is not true for the ColdFusion solution. So let’s take a closer look at it.
Because of the help of the Mach II Framework our control-flow is now managed in one file, mach-ii.xml. While this is a great thing there are some declarative options missing. It is said that listeners shall only be used as facades to let business logic not depend on the framework. But there is no possibility set up a reference to these framework independent components, declare basic properties like the name of the database and reference these components in the listeners.
The control-flow shall be handled in the event-handlers. But because no simple if-else statements can be declared, some logic has to be moved into listeners. This produces mishmash of event-handler and listener managed control-flow logic.
Another problem for a programmer who knows what listeners, events and event-handlers are is the naming. For example listeners that should be nontransparent for event-handlers are this not at all. The event-handler even decides which method to call on the listener and where to store the result. An even-handler is a on xml-basis declared method that handles the control-flow.
A disadvantage is also the, at least for me scaring, tag-based object-oriented scripting language. As well as the fact of bad type checking, the inability to use interfaces and other useful object-oriented constructs.
This is at least my experience so far. So, my question is, why are people working with ColdFusion?
6 Responses to “ColdFusion vs. Java”
Here are things I noticed in your arguments which I think should be made clear:
1. you’re comparing frameworks not languages. 2. Mach-II is an MVC only framework while Spring is an application framework which provides management of MVC, transaction, and application context. NOTE: application context and transaction support are provided by ColdFusion out of the box.
3. both Mach-II and Spring promotes good programming practices
4. tag-based scripting is more natural in the presentation tier than any other programming implementation, otherwise why do we have JSP tag libraries? The same trend happens in Rich Client development.
1. Yep, I am probably mixing the comparison of frameworks with programming language comparison.
4. I fully agree. But in my eyes a coldfusion component does not have much to do with presentation. Neither do database queries.
2. Know that too. But Spring is also offering support for MVC in the presentation tears. And I think the two can be compared.
3. Also right.
“But there is no possibility set up a reference to these framework independent components, declare basic properties like the name of the database and reference these components in the listeners.”
Confused about this one… did you look at the property manager?
Simply, because ColdFusion is a markup-language, that has a more naturual and logical flow.
ColdFusion is reknown for it’s rapid application development. Speed of idea to completion.
Java is much more detailed, takes longer, costs more in developers.
Although ColdFusion code can be done wrong, but if planned, organized, documented thoroughly, they can create efficient applications.
Coldfusion is also much easier to learn, if you know HTML, you can easily learn ColdFusion.
If you need to show some code to your boss, to make sure it follows his business rules, it’s easy for anyone to read to follow the logic. With Java that is nearly impossible, because of the object-orientation.
Having frameworks is nice, as long as they are not oop frameworks.
Simon,
I second Dave about looking at the PropertyManager. This object holds all the values defined in the “properties” section of the configuration file, and it is available to any components that extend the framework (event handlers, plugins and filters) for both reading and writing new and existing properties at runtime.
“But because no simple if-else statements can be declared, some logic has to be moved into listeners. This produces mishmash of event-handler and listener managed control-flow logic.”
If you haven’t already, take a look at filters. In general, they control the conditional flow of login in the request. They can access the eventContext and clear the event queue, stop the execution of the current event, announce new events, display/call views, and any other processing that is secondary to core business logic in the application.
They are commonly used as a means of interacting with HTTP specific things like cookies, http headers, request scope, client scope, cgi scope and more. Filters are also used to facilitate data persistence, authentication and authorization, and i18n.
Really, listeners can do this, but many times filters can do a better job of isolating the business layer from the controller and the presentation layers. Also if there is something that MachII doesn’t do, but is essential for your application, you can write a filter that essentially extends the utility of the framework. Filters are the declarative equivalent of custom tags in a runtime environment.
Something elso that you did not mention is the plugin. This is very handy for pre- and postprocessing of the request, its events, views, unchecked exceptions, and application initialization.
“As well as the fact of bad type checking, the inability to use interfaces and other useful object-oriented constructs.”
Actually, if you use CFCs with tag-based functions, you can utilize all sorts of runtime type checking of both built-in types as well as components for method return types and parameters. As far as interfaces go, there is a lot that can be done without having to use them. Sure they make many designs easier to implement–especially if you are familiar with all the Java-centric literature regarding patterns–their absense doesn’t make them any less possible. There are many other languages that do not support interfaces such as Smalltalk which is considered by many to be the purest form of OO around.
“…there is no question that the application written in Java is more flexible and easier to maintain.”
This is very often said of CFML as well… I guess it depends on where you’re coming from.
Anyhow, I am glad to see that you tried MachII and even went on to see how it compared to a Java implementation.
I’d be interested to see if you would be interested in revisiting your Mach-II implementation and find places where you could move code out of your listeners and into filters. Also, take a look at using the PropertyManager for getting/setting properties at runtime from within your listeners and filters(if any). A couple of tags that will help decouple listeners from the control-flow are “event-mapping” and “event-arg”.
First of all, thanks for all the helpful responses.
I actually used the PropertyManager in the sample application that stays for download. I used it to get the string path to the framework independent DAOs. But these are as said only string paths and not instantiated components one can use directly. I have to instantiate them first and set a few basic properties. It would be cool if this instantiation could be done automatically and if the component dependent properties could be set via the xml file (not global properties).
I am also already using filters for login validation.
The if-else problem was related to a component that made database queries and originally returned true or false depending on success or failure. And I just would have liked to make the if-else check in the event-handler. A filter is not appropriate in this specific case.