coldfusion

My Move From ColdFusion to Java Development

by on May 27, 2014 8:25 am

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 statement.

 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.

— Dmitry Kolesnikov, asktheteam@keyholesoftware.com

References

  • Share:

7 Responses to “My Move From ColdFusion to Java Development”

  1. Brad Wood says:

    You mentioned twice in this article that CFML is interpreted, but this is not true. In both Adobe ColdFusion as well as open source Railo it is direct-compiled to Java bytecode and cached. Also, CFML doesn’t need to be tag based– all language features to available in script.

    Regarding tooling, have you used the official IDE, CF Builder? It is built on Eclipse, is extensible via CFML, and includes functionality such as step debugging, component introspection, and code hints. The reason these features are difficult is because CFML is a dynamic and loosely typed language, not because of the way it is compiled.

    I appreciate your commentary on the pitfalls of “rapid” development but I’d like to point out that fast and loose development is an *option* with CFML, not a requirement. In other words, one can still design a well-architected application with little to no technical debt with CF — and do it in my opinion still faster than lower-level languages like Java that lack inbuilt features like hibernate, enterprise integrations, and productive convention-over-configuration frameworks like ColdBox MVC, and WireBox. The difference for me is if you want to throw a prototype together for a client, you can still do that with CF, but it’s not really an option with Java. I’m a big fan of Agile, and a key principle of Agile is having a short feedback loop.

    Since CF runs on the JVM and has great interop (use Java classes in CFML, use CF components, in Java, etc) I see it as the best of both worlds. I would also disagree that how to use Java classes are “undocumented”. CF simply provides the bridge– it’s not CF’s job to duplicate documentation for every Java class out there.

    • Dmitry Kolesnikov says:

      Hi Brad,

      Thank you for writing. I do agree with nearly all of what you mentioned. Perhaps my experience with ColdFusion is reflective more of the environments ​in which it was used rather than the capability of the technology itself. ​This post has been a reflection based on my personal experience.

      Regarding the architecture, I have seen beautifully laid out projects on Github​. Unfortunately, I ​have​ yet to see it in production anywhere I’ve worked.

      You are​ also​ right about the extended script capabilities in CF9 and later (and ​version 8 to some degree), but many small business are still on ​v​ersion 8 with no set timelines to upgrade. I ​have yet to see ​version 9 running in production.

      Regarding compiled versus interpreted, what if caching is not enabled? Would you enable caching during development?

      I do know about CF builder and have heard great things about it, but I could never convince my manager ​ to purchase it​ (​in a ​role previous to Keyhole Software)​. I have also used step debugging capabilities, but, depending on how your development environment is set up, it can be difficult to get working. I also used Fusion Debug at one company, but that license is often viewed as unnecessary overhead cost that is incurred at the discretion of management.

      It feels to me that everything within ColdFusion works quite well in theory – it can be incredibly effective and meet the needs. But in my experience in its not-so-purest form, it just wasn’t a good fit for me and what I wanted to accomplish. It’s all a matter of perspective and based upon one’s experience with the language, for sure. Thanks again for reading and for sharing your perspective.

      Thanks,
      Dmitry

      • Brad Wood says:

        > Regarding compiled versus interpreted, what if caching is not enabled?

        Caching has no bearing on compilation. CFML is never interpreted, it is always direct compiled to bytecode and executed with the same scalable performance as a native Java application. By default, it is JIT compiled, though CFML can be precompiled, and even distributed as a WAR for deployment on your servlet container.

        > Would you enable caching during development?

        It depends on which setting you’re referring to.
        – Trusted Cache: No
        – Cache Template In Request: Yes
        – Component Cache: No, if you’re using multiple sites with app-mappings
        – Save Class files: Yes, but it may use a lot of disk space on dev.

        Regarding people who use old versions of CF: Upgrade. Now. There’s really no excuse, and if you’re using open source Railo, it’s free. This excuse is a non-starter and a cop out in my opinion– ESPECIALLY given the security patches that have came out in the last year or so. When you switched to Java, did you move to Java 1.2? I hope not. To be fair, you need to compare the latest iteration of each platform.

        Regarding companies who don’t want to spend money on tools: What a fabulous waste of company resources for them to complain that you want something that makes your life easier but costs $299. (I got my copy of CFBuilder for free for attending CF Summit last year) If it just saves you a couple hours a week in productivity, it will have paid for itself almost immediatley. Show this article to your manager and point out item #9:
        http://www.joelonsoftware.com/articles/fog0000000043.html

        Regarding whether you’ve seen good code in your production servers: Whose fault is that? :) Create development guidelines for your team and enforce them via code reviews. Here are the set I use:
        http://wiki.coldbox.org/wiki/DevelopmentBestPractices.cfm
        Adopt a good MVC framework like ColdBox (Full disclosure, I’m on team ColdBox). If you can’t bring your team to write code you’re proud of with CFML, what makes you think your Java applications will be any better?

        I realize that sounds a little terse, but it’s not meant personal. These are very good questions that every development team comes to and they are worth answering. The answers for me, lie in your processes and people much less than your language platform.

        • Hi Brad,

          It’s hard to disagree with you.

          I was never in the position to make decisions about any of those aspects, however, because I was a developer, not a manager, or team lead, or architect, or CTO. So this is my review from the standpoint of a developer who was given a task to work on, having just begun my career as a full-time developer. Thanks again for reading and for sharing your perspective.

          Thanks,
          Dmitry

  2. […] Continue Reading : My Move From ColdFusion to Java Development […]

  3. Adam Cameron says:

    Brad, whilst I think there’s some gaps in Dmitry’s technical understanding of and exposure to CFML, it doesn’t detract much from what he says here.

    Especially if one considers the *perception* of CFML as well as the reality. Although Dmitry’s right on the button with most of what he says regarding the *reality* of CFML too.


    Adam

Leave a Reply

Things Twitter is Talking About
Keyhole Software
8900 State Line Road, Suite 455
Leawood, KS 66206
ph: 877-521-7769
© 2014 Keyhole Software, LLC. All rights reserved.