ColdFusion Migration to Java or .NET
Migrating ColdFusion to new languages such as Java or .Net promises the following nice properties:
- makes the application more maintainable, and easier to enhance due to the enormous libraries available for Java and C#
- enables some degree of automatic bug detection by virtue of (Java) compiler static analysis, which does not/cannot occur with ColdFusion so many such problems are found after deployment,
- moves it to modern web technology such as JSP or Java Server Faces/PrimeFaces, enhancing productivy and users' UI experience
- provides the organization with access to more easily found (Java) software engineers,
- all which contribute to faster turnaround on desired changes for management.
A key concern is, What will translated code look like? Weak translators convert code blindly line-by-line, with virtually no understanding of how the context of the code should shape its translation. Such translated code preserves the properties of the original ColdFusion, sometime the point of even preserving the syntax. Even if such code works, it not be maintainable and will ultimately cost the organization sorely.
Semantic Designs translators parse the original code with tools that have the same understanding as the original compilers; (for example, see our ColdFusion Front End). ColdFusion doesn't really provide declarations of variable types, so SD's tools need to infer appropriate Java/C# types based on how variables are used in the program, where and how they are used ("the context"). Using this information the translator can thus produce extremely good translations. Because SD also customizes the tools to the specific needs of the customer, the code reflects those needs properly.
A ColdFusion program translation
Here we show you a small sample of ColdFusion translated as SD's technology could translate it to Java.
A simple ColdFusion program
We have chosen to provide a small ColdFusion program to prevent the reader from being overwhelmed by the complexities that occur in real examples.
<cfquery name="Item" SQL="Select Name,Quantity,Cost from ItemTable"</cfquery>
Each client has different goals and these can change the chosen target technology.
- Target language of C# or Java. Given that ColdFusion has been built on top of Java, that tends to be the strongly preferred target for most ColdFusion migrations.
- Generation of web pages using Java Server Pages style (similar to legacy ColdFusion), which provide for an easier migration but requireds the web developers to build their complex widgets, or using a more modern UI framework such as Java Server Faces and possibly its extension, PrimeFaces. Choosing the latter gives the website engineers libraries of well designed and tested UI components with which to build a rich user experience. A key issue with using JSF/Primefaces is whether to fold multiple legacy HTML pages together into single DOM image with dynamic updates using Ajax.
- Mapping of database queries to the client's database of choice; this may be complicated by the fact that SQL only appears to be standard across databases.
- Usingly legacy HTML constructs such as
or using Primefaces components such as Accordion tables.
One should note that the translator must chose fixed data types for variables compatible with their usage in the ColdFusion program or the database schema, but with a different representation better suited for Java. Note the different choice of Java integer types based on the sizes of the values being stored.
In particular, note the choice of the Java BigDecimal class used where ColdFusion values represent fractional or very big numbers. The translation is adjusted to use appropriate method calls on the BigDecimal class instead of native Java operators +, -, *, / which do not work on classes. We remark that a different custom translation could scale decimal numbers by 100 or 10000, allowing use of Java-native + and - operators instead of method calls. Which of these choices are made depend on what the client thinks in more important to long term maintainablity: representation of decimal numbers as 'decimals' in the BigDecimal class with somewhat less readable expressions for decimal arithmetic, or a slightly non-intuitive representation of decimal numbers with readable expressions.
Which combination of choices is made can determine very different style of translated code. The translator needs to be configured to account for the client's choices. For this example, we have chosen to use PrimeFaces. The translator produces nicely formatted code as a standard by-product.
ColdFusion program automatically translated to Java
TRANSLATED DEMO APPLICATION HERE
One can get good code from a translator, if one has the right foundation technology such as SD's DMS Software Reengineering Tookit®. As a practical matter, you can't get good code from an off the shelf translator, because every application system has unique properties: languages, OS features, scripting languages, screens, databases, and a correspondingly unique set of target technologies as decided by the client. It takes some effort to configure DMS for the client's particular source and target software configurations. The effort is rewarded by the maintainablity of the result.
Configuring a custom migration tool to match client needs
Semantic Designs can provide custom configuration of migration tools and migration support to your organization, providing high quality, maintainable code translations.