BarneyBlog

It's pretty common knowledge that ColdFusion passes arrays to UDF by value, and not by reference like pretty much every other language.  It's a weird behaviour, but as long as you remember to write array-processing functions to be used like this:

<cfset myArray = modifyArray(myArray) />

instead of like this:

<cfset modifyArray(myArray) />

you'll be fine.  However, someone pointed out on the Railo mailing list that this behaviour is not constrained to UDFs.  Assignment behave the same way!  Yes, if you assign an array to another variable, you get a copy.  The only "assignment" that is exempt from this behaviour is if you use structInsert.

Consider this code:

<cfset a = [37] />
<cfset a2 = a />
<cfset s1 = {array = a} />
<cfset s2 = {} />
<cfset s3 = {} />
<cfset s4 = {} />
<cfset s2.array = a />
<cfset s3["array"] = a />
<cfset structInsert(s4, "array", a) />
<cfset arrayAppend(a, 42) />
<cfset System = createObject("java", "java.lang.System") />
<cfoutput>
<p>#System.identityHashcode(a)# - #a.toString()#               <!--- [37, 42] --->
<p>#System.identityHashcode(a2)# - #a2.toString()#             <!--- [37]     --->
<p>#System.identityHashcode(s1.array)# - #s1.array.toString()# <!--- [37]     --->
<p>#System.identityHashcode(s2.array)# - #s2.array.toString()# <!--- [37]     --->
<p>#System.identityHashcode(s3.array)# - #s3.array.toString()# <!--- [37]     --->
<p>#System.identityHashcode(s4.array)# - #s4.array.toString()# <!--- [37, 42] --->
</cfoutput>

At the end of this code, there are five distinct arrays, one containing 37 and 42, and the other four containing only 37.  The blue lines create the four copies, and the red line creates a new "pointer" to the existing array.  Then when the green line executes the original array has 42 added to it, which only affects 'a' and 's4.array', because the rest are copies.

On Railo, arrays are universally reference types, so there would only be a single array in the above example.  This is consistent with most other languages.

Just completed my first port of a major app from ColdFusion to Railo.  Time elapsed from downloading the Railo WAR to my dev box to see if the app would run to reenabling the prod instance: 1.5 hours.

Downloaded the WAR, unpacked it into my webroot, unzipped a new Tomcat, set up a Context pointer to my webroot, and fired it up.  Worked like a charm, and after adding my DSN to the config file, the app was running.

I had to make a couple minor tweaks for Railo compatibility:

1. Railo seems to stick getContextRoot() into cgi.script_name automatically, so I had to remove the function calls in my 'self' variable's definition
2. Railo has an issue with non-defaulted, non-required, numeric method arguments that are omitted from a call.  I added it as bug 147 in JIRA.

After that I just checked /WEB-INF/ and the tweaks into Subversion for deployment to production.  On my prod server I did basically the same process: unzip  a Tomcat, set up a Context pointer to the existing webroot, configure an init script, and fire it up.  Once Tomcat was happy (first try!), I took the Alias directive out of my Apache config, replaced it with a mod_rewrite proxy directive, redeployed the app (to get /WEB-INF/ and the tweaks), changed the DSN credentials, and bounced Apache.  Done.  Live.  No errors.  And cookie-based session tracking worked flawlessly across the engine replacement.

Needless to say this is a HUGE win for both me and Railo.  I've been writing new stuff to Railo, but hadn't ported anything substantial because I didn't want to deal with the pain.  But with how minor the pain is, it's totally overshadowed by the benefits of separate contexts (or VMs!) per app.  That was never really an option with CF because of the memory footprint (350MB for CF vs 60MB for Railo).