My ColdFusion 8 Upgrade

I just upgraded my workstation to ColdFusion 8 today, as well as installed it on my server (though it's just testing at this point).  Since it's my first real-world CF8 experience, I figured everyone would want to hear all about it, especially the new features that made the process much easier.

The real motivation for the upgrade was the refusal of the 7.0.1 and 7.0.2 installers to upgrade my 7.0.0 CF instance, saying it wasn't a valid JRun.  I suspect it's because it's actually a CF6.1 JRun with a CF7 instance inside, but whatever.  I opted for installing CF8 into it's own separate JRun to avoid that potential issue down the road.

First off was the automatic upgrade migration.  I have no idea how it works, because I didn't tell CF8 where my CF7 lived (and it wasn't in a "standard" location), but it worked.  Kudos for that.  Next up, poking around the administrator, I noticed the setting to disable runtime CFC type checks, which is a nice way to get the benefits of type checking during development without the performance overhead in production.  I'm surprised I hadn't heard of this feature, as it definitely adds a new dimension to the perpetual "duck typing in CF" debate.

The next bit was converting my old MySQL datasources to the new built-in Connector/J.  It would have been nice if there were a button to convert an old (3.x)  datasource to a new (4.x/5.x) one automatically, but I only had 10 or 12, and they were manually dispatched in five or six minutes.

At this point, I had live code, and I wanted to play with the new server monitoring dashboard, but being a Flex app, it repeatedly crashed Firefox (on Linux), so I gave up.  The demos gave the impression that it's pretty slick, but I guess I won't know until we get it loaded at work (where we run Windows).  But it's a "candy" feature, so a glitch (even a fatal one) isn't a big deal.

Digging into the code a bit and I realized the ByteArray issue with the new MySQL drivers is pretty commonplace, so I had to do some recoding (adding explicit casts to CHAR) of my apps to get them to work right.  No big deal, and definitely worth it for the newer drivers.  If you're not familiar with the problem, certain functions (GROUP_CONCAT in particular) end up returning a ByteArray instead of a string, which CF balks at using.  Casting to CHAR in the DB, or using as the source of a new java.lang.String in CF both resolve the problem – take your pick.

Next was refactoring to use the new image manipulation libraries instead of my custom stuff.  I'd used the Alagad component from one of the DevNet CDs as my base, and then subclassed it to add various other manipulations I needed.  Unfortunately, something's wonky with the JAI upgrade, because all the ops I tested using Alagad and my extensions ended up with color-thrashed images, so that kind of forced my hand before I was ready.  Since I still have to run on CF7 (in production) I couldn't just do a wholesale replace, but CF8 and ColdSpring saved the day.

Using the import functionality of ColdSpring, I split my beans XML into version-specific beans and general beans, and then use a version switch to pick the right XML to load into the factory.  All well and good, but typechecks still happen, and I didn't want to have my CF8-based manipulation object have to extend my Alagad subclass.  CFINTERFACE to the rescue!  Moved my subclass from Image to ImageImpl_CF7, created a new Image interface for it to implement, and then added a second implementation that is based on the CF8 built-ins.  No type changes anywhere in the application.  Sooooooooo nice.

I was happy to see that CF8 exposes a imageGetBufferedImage() for returning the java.awt.BufferedImage backing a CF Image object ,so you can still do your own raw manipulations as part of a pipeline based on CF8's built-ins.  Fortunately, CF8 covered all the extensions I'd added to Alagad, so all of my custom stuff was unneeded.  The built-ins also seem to be faster than what I was using before, which is nice.  I assume there's a bunch of native code in there (thanks Photoshop!) rather than an all-Java solution.  Didn't do any format testing, but generating piles and piles of thumbnails seemed to progress faster than I recall with CF7.  I'm not sure the quality is as good (it didn't look like it), but in the absence of empirical tests (or even a comparison of the JPG compression settings), I'll withhold judgment.

I also noticed is a couple minor changes to CSS processing of CFDOCUMENT.  Nothing really broken or fixed compared to CF7, but wrong in different ways (not respecting print stylesheets correctly – while both FF and IE do it right).  Nothing I'm going to try and go work around, but it'd piss off branding Nazis, I'd wager.  ; )

I didn't get a chance to play with per-application mappings, because unfortunately they're only available from Application.cfc, which has some problems (like onRequest shadowing remote CFC calls).   This is probably the biggest feature I'd want, because I hate having to keep all my apps running on identical ColdSpring, but rearchitecting to get deal with Application.cfc is a big burden (heck, it's a burden even for new apps).

Things got a bit worse with the test install on my production server.  First, the wonderful browser requirements for Adobe.com (which I've complained about before) necessitate downloading locally, and then immediately pushing it right back out.  My bandwidth is free, but it still takes a while to feed that much data across the wire twice.

Next was trying to get JRun to start on system init.  CF7 (I have Standard Edition) has a reasonably nice installer for a init script.  Nothing with a multi-server install of CF8.  I'm assuming it's the "multi-server" that is the problem, but it's still just firing off JRun either way, so I'm not sure what the distinction is.

Connecting to Apache was a dream – the best connector experience I've had with CF6+.  I've never been stuck up a creek, but there's usually been some little glitch somewhere.  Both machines – no problems.

And as a final extra benefit, CF8, courtesy of it's built-in LiveCycle Data Services has server-side Flex compilation, so the refusal of the web connector from Labs to work on my machines is no longer an issue.

All in all, a solid release.  Now I've got 30 days to determine whether or not it's worth paying for the upgrade for the server.  None of the feature improvements really justify the cost (monetary and otherwise), but keeping current has a tangible value, so the $649 is probably right on the cusp of "reasonable".