My Move From ColdFusion to Java Development

Keyhole SoftwareMay 30th, 2014Last Updated: May 29th, 2014

0 23 5 minutes read

Although I studied and experimented with different development technologies and tools throughout my college and graduate careers, my full-time professional career began with development in Adobe ColdFusion.

Coming out of school, solving real-world business problems using technology was a challenge in itself. Due to its fairly uncomplicated nature, ColdFusion did not stand in the way of getting things done. It allowed me to apply the main principles of application development, too. Over time, however, I began to notice that the tool set offered by the language was not as rich as that of other development technologies like Java, for example.

Eventually I developed a desire to work more closely with a more complex but rewarding language, and that is when I transitioned to Java. I often think of this transition as going back to my roots, since my first meaningful experiences developing applications were in Java. This blog will discuss some of my thoughts and experiences in making the transition.

ColdFusion – making rudimentary tasks easy

In a typical web application stack, ColdFusion is the server-side development technology that fulfills requests received from a user’s web browser and sends meaningful information back. ColdFusion is a tag-based language that integrates with HTML very well. It can also stand on its own in an object-oriented manner, but that doesn’t change its purpose.

While I was still working with ColdFusion, my experiences were providing me with piecemeal hints about the sort of resources Java has in store. Because ColdFusion itself is a higher level interpreted language that runs on top of Java, it was possible to use the Java underneath in creative ways. For example, the following code snippet allows to remove duplicates from a ColdFusion array in a single statement1.

myArray = createObject("java", "java.util.ArrayList").init(
  createObject("java", "java.util.HashSet").init(myArray)
);

These techniques, however, were by and large undocumented. You would already have to know some neat tricks in Java in order to apply them in ColdFusion. And if that’s the case, why not invest time in getting better at Java? I believe that ColdFusion has progressed considerably over time, but only to uncover and implement what Java already mastered.

While the underpinnings of the two technologies are very similar, ColdFusion has a specific purpose on the market. It prides itself on making rudimentary tasks easy. For example, database access facilities in ColdFusion are very laconic, especially for the time when they were first introduced. By virtue of this sort of ease of use, ColdFusion has created a reputation of being a Rapid Application Development platform. Not only are the server-side facilities convenient to use, the language offers some out-of-the-box UI components that can potentially save development time and, arguably, relieve the developer of front end duties to some degree.

It sounds good in theory. In practice, however, the UI widgets are too rudimentary to be used in any modern real world application, especially considering the front-end libraries that have emerged in recent years, not to mention the emerging capabilities of HTML5. The built-in shortcuts for making AJAX calls do seem elegant, but they are often not flexible enough for all scenarios, so you would end up resorting to more robust jQuery anyway.

When you only take the good parts, ColdFusion is “just another” server-side technology that also happens to bring an organizational culture along with it, or it creates an organizational culture that, in my opinion, is not ideal for the long term.

Rapidity

The notion of Rapid Application Development is often misconstrued. In fact, the rapidity of it doesn’t seem to buy you much in the end. Especially when first setting up an application, a fair amount of thought and planning should be given to the architecture. If the proper architecture is in place, making enhancements to the application will not be terribly tasking.

On the other hand, if something is developed “rapidly” and hastily, the inevitable technical debt will be forever weighing you down, as it is much harder to justify spending the time to refactor an application than to create an enhancement. Often times, refactoring takes longer, introduces system-wide bugs, which requires additional QA resources. The more that I continue with this thought, the more I realize how important it is to get the foundation right and the word “rapid” doesn’t seem appealing in this context.

With that in mind, I have experienced different performance expectations in workplaces where these two technologies are used. As you might have guessed, the timeframes for completing functionality have been consistently more demanding where ColdFusion is used. I am definitely a proponent of productive working environments, but I also believe there should be a balance between delivering functionality and maintaining the code base in such a way that future enhancements and fixes can be completed more easily.

It is difficult to maintain a culture of quality when the focus is on the application features alone. I have found that environments where more sensible architecture is used allow for some “buffer time” to leave the code base a better place than when you encountered it, much like the Boy Scout rule.

Tooling

Another point worth touching on is the level of sophistication and usefulness of the development tools. Both for my ColdFusion and Java development work I utilized Eclipse as the integrated development environment. Eclipse is traditionally known as a Java IDE. However, due to its extensibility, ColdFusion development can be facilitated via a plug-in. While the community support for this plug-in is excellent, it is no match for the code inspection and debugging tools available for Java. I tend to think that the difference is due to the fact that Java is a compiled language, whereas ColdFusion is interpreted at runtime.

Whatever the case, considering that Eclipse is a free resource, it improves developer productivity tremendously. It was a rediscovered luxury when I started working with Java in my professional career. I became convinced that it is not necessarily the development technology itself that can save you time, but the tools you use throughout the development process. The access to useful tools available at no cost certainly makes Java a leader in this comparison.

Final Thoughts

Whether incidental or not, different technologies seem to foster organizational culture to a certain extent and have their own strengths and weaknesses. Ultimately, no matter what you prefer to develop in, it is important to continue to grow as a professional and to challenge yourself to find new and creative ways to use a technology or development language. I have found the Java platform to be very rewarding in this regard.

Learning something new everyday might seem overwhelming, but, just like in the case of performing physical exercises, the mind becomes more effective over time.