Monday 5 August 2013

Java 6 to 7 migration: a paucity of gotchas

After some confusion arose from changes in behaviour of arraySort() if running ColdFusion 9 on either Java 6 or Java 7, Ray encouraged me to have a look into what problems people had had / were having, so I ran a quick survey to try to elicit this info from people.

Unfortunately there wasn't much info to be had. I only got seven responses, and three were to say "no real problems". Well I say "unfortunately", but I guess that's actually good news.

So, in short (because I don't have much material), here are the survey results.

Sorry, don't have code samples, but did want to mention a lot regex's broke when moving to 7.
I've experienced this by proxy. Well: not a problem with Java 7 regexes per se, but changes to the Java API which ColdFusion's limp type casting falls afoul of. In Java 6, the group() method of Matcher is overloaded twice: group() and group(int), whereas Java 7 has three varieties of this method: group(), group(int) and group(String). The difference between the int and the String overloads are that the int version returns a numbered capture-group, and the String version returns a named one. The latter being a new feature in Java 7. This causes problems in CF because CF is likely to just have a variable which is a numeric string to use as the group reference, and in Java 6 the requirement is "int", so CF seems to cast it to an int correctly; however in Java 7, CF can't know whether it's the int version of the method or the string version, so just calls the string version, and errors ensue because it doesn't find a named capture group with that numeric name, if that makes sense.

So if one encounters this sort of behaviour: use javaCast() to force your numeric reference to be an integer.

I'm unaware of other issues, but the regex grammar in Java 7 did get a few enhancements, so look out for this. Note: this does no impact CF's internal regex engine, as it's a dusty old implementation or Apache ORO, which is never going to see any unexpected enhancements, as the project was mothballed almost three years ago, having not had any activity for almost ten years. Way to keep apace, Adobe!

Next was this comment:

Only had to update some third-party Java libraries, for obvious reasons.

This stands to reason and ought to be expected if one is not simply using ColdFusion, but also extending it with additional Java stuff. Not really a ColdFusion issue, per se.

The only real problem we've encountered is the issue with XMLSearch() and ColdSpring 1.2 under JDK 1.7 and Adobe CF10. See!topic/coldspring-users/AqyrBnS_FD4 This problem occurs on 64-bit Windows 2008 R2 in addition to Linux. The problem does not prevent our large Mach-II application from starting up (the OP said that his app would not start up), but we do get a good number of error messages when our large app starts up.
There's also a bunch of info about this on the TransferORM Google group. It seems some changes in Java 7's XML libraries can cause issues with xmlSearch() (I didn't read the thread that closely, but that seems to be the gist of it).

When using Java 7 (1.7.0_15...latest Adobe-certified Java version), dates of datatype "date" (SQL Server) are mangled in be more specific, the dates are exactly two days prior to the actual date stored in the database (e.g., 5-22-2013 is 5-20-2013 in CF). This occurs whether data is retrieved via CFQuery or ORM. Here's the full bug report:
This is the only one of these that is pretty mainstream (as opposed to quite edge-case, I think):it sounds pretty serious to me. Indeed I'd say - taking it on face value - that'd be a bit of a show-stopper for using Java 7. I'm surprised this has not got more attention. I might have a bit of a play around with this when I get a moment.

The last one was my own experience with arraySort(), as mentioned above. I haven't raised a bug for this yet as I meant to test it on ColdFusion 10, and have not got around to it yet. Oops.

Oh... one last one: not Java 6->7-related, but ColdFusion upgrade related. I've recent heard of someone mulling over the benefits of upgrading their ColdFusion 8 environment, and drew a conclusion that as there was nothing compelling in CF9 or CF10, there perhaps weren't going to bother. This is bad practice, bordering on professional negligence in my opinion. ColdFusion 8 is unsupported technology, so will not have any security issues that might arise dealt with. Also I dunno how well CF8 will run on Java 7 ("supported versions" become a bit of a moot concept as CF8 itself isn't supported any more), so you'd be on yer own as far as Java security issues go too. If you're still on CF8, make sure everyone who is in the reporting chain knows about the decision to run potentially insecure servers. If you don't want to pay the £££ to upgrade to CF10, consider migrating to Railo instead. But have a think about whether it's really the right thing to do do continue running on outdated / potentially insecure application servers. Sometimes the answer could legitimately be "yep, no probs", but it's a consideration one ought to make before just not doing anything about this.

So no tragic disasters, which is good news. I suppose we would have heard if there was anything crazy going on. The bottom line is to remember to run all your unit & regression tests (which you have got, yeah?) before doing upgrades like this, and also remember to check any direct Java usage you are doing: there could be changes there too.

If you have experienced any other vagaries of running CF on Java 7, pls let me know.