CFML differences between Railo and ColdFusion 9/10 (Part 1)

As promised in my last post, I’m starting a short series of observations I made when working with clients here in Australia and New Zealand on porting CFML applications between ColdFusion and Railo.

Please note that this post (and the follow-up posts) is not meant to be judgmental in any way, it’s just supposed to deliver a neutral view of what I found to be different when working with real-world client apps. Both products have some subtle different takes on things and I think it’s very valuable to have at least some of them documented.

1. General observation: Railo is sometimes more strict on CFML

Take the following code example:

switch(arguments.action)
{
  case("approve"):
  {
    doSomething(arguments.whatever);
  }
  case("delete"):
  {
    doSomethingelse(arguments.anotherargument);
  }
  default:
  {
    //no action
  }
}

What would be wrong with this? Besides the fact that are are no break statements at the end of each case block (which might be intended), the way how the case statements are expressed is quite weird, isn’t it? Normally I would write a case statement more like: case “approve”: and not wrap the additional parentheses around the string to test for.

ColdFusion accepts the example above just fine (I personally think it shouldn’t, but that’s a different discussion) – Railo however stumbles over it at compile time. It turns out that it tries to parse case(“something”) as a function call (makes perfect sense to me) and as it can’t find a local function case, it doesn’t compile the template. This can obviously easily be fixed by removing the parentheses.

2. Boolean and how they convert to Strings

If you convert Boolean variables into Strings, it seems to me that Railo will always convert the value true into the String “true” and the value false into the String “false”. ColdFusion does that only at compile time. At runtime, true converts to “Yes” and false converts to “No”. I think this runtime behavior is essentially due to some backwards compatibility behaviour going back very, very far in ColdFusion’s history.

This would usually not create a big issue unless you output converted Boolean values to the screen, but can be easily fixed with some conditional logic or a quickly written conversion function if needed.

Here’s an example:

#true#
Output in both Railo and CF: true

#1 EQ 1#
Output in Railo: true
Output in CF: Yes

3. Different approaches when storing simple types

This is slightly related to the item above. ColdFusion stores simple type literals internally as String – this can be easily verified by running some Java reflection code against your CF variables. There’s nothing inherently wrong with that, it’s just the way how the ColdFusion team back in 2001/2002 decided they’d implement variable management when the move was made from ColdFusion 5 to ColdFusion MX.

Railo follows a different approach. In the majority of scenarios I’ve seen, Railo seems to preserve the originally intended type. Something like myBool = true; or myDouble = 5678.91 would be stored in their native Java types. This can in some instances create a performance advantage as conversions between String and the original type might not have to happen (that often). Does it make a big difference? Yes and No (and I’d have to do more and proper measurement to confirm that): If you were to convert between a String and a Double, let’s say, 10 times, it won’t have much of an impact. If you however had to do that 20 million times in a loop, I’m very, very sure your users would actually feel the difference very clearly.

More important though: There are some other instances where the two different approaches bubble up quite unexpectedly; think of serializeJSON() for instance:

serializeJSON(456);
Output in Railo: 456
Output in CF: "456"

Wrap-up of part 1

Not unexpected, there are differences in how ColdFusion and Railo treat certain parts of CFML. As said above, I’m not judgmental, I have a vested business interest in both Adobe ColdFusion and Railo being successful with what they’re doing. This series is just about making people’s life a bit easier in case you have to port an application in either direction. So much for part 1, I’ll hopefully probably get round to write and publish part 2 tomorrow, there’s more to come.

Tagged as: Adobe, CF, CFML, ColdFusion, Railo