1. refocus on the original objective, inline Groovy scriptlets
2. support Open BlueDragon

The first objective is based on my experience developing the last couple apps I've used CFGroovy on.  Hibernate is kickass, but neither of the apps used it; they only used CFGroovy for scriptlets.  What I discovered was that while using CFGroovy is pretty simple, it's not really all that friendly towards a pure-scriptlet use case.  Adding Hibernate provided a huge boost in capabilities, but it also roughed up the edges of the core Groovy engine quite a bit more than I had realized, and you pay the price regardless of whether you're leveraging Hibernate or not.  As powerful as Hibernate is, I still think scriptlets are the real win.  If you get scriptlets, Hibernate becomes just another Java API you can easily leverage from CFML.

So I've started going back through with a focus on smoothing those things back out.  The specific objective is to be able to download CFGroovy, drop the JAR into my /WEB-INF/lib folder, CFIMPORT the taglib, and run <g:script> in a production-ready fashion.  Obviously it can't hope to support a custom classpath, precompilation, Hibernate, etc., but that's not the point if you just want scriptlets.  There's no reason CFGroovy can't support both use models equally well.  Immediately following that objective is that taking an app and "upgrading" to a more customized CFGroovy configuration should be transparent to the code.  Just new configuration in Application.cfc or ColdSpring and the app automatically adjusts.

And yes, CFGroovy no longer bootstraps itself into it's own little world, including loading it's own Groovy JAR.  Compared to spinning up Hibernate the cost of doing that is a drop in the bucket, but it's not acceptable for my above-stated goal for various reasons.  So I've reverted to requiring installation of the JAR.  Certainly an added hardship, but to get production-ready performance and memory consumption out of the box, it has to be that way.  It also makes the internals enormously simpler.

The other major change is that CFGroovy is no longer implemented in Groovy, it's 100% CFML again.  This is for much of the same reason as the JAR loading: the price is too high in terms of performance and memory consumption for the pure-scriptlet class of development.  I'd rather implement in Groovy than CFML because everything is Java APIs, but bootstrapping a Groovy environment to bootstrap the CFGroovy environment effectively doubles the initialization work.  Only measured in tenths of seconds at the most, and therefore invisible if you're spinning up Hibernate, but a non-trivial penalty if you aren't.

Second, Open BlueDragon support is mostly there.  The pre-1.0 releases had some classloading issues that prevented stuff from working, so I just wrote it of.  However, I decied to give it another try tonight on a whim, and those issues seem to be resolved.  The core CFML->Groovy->CFML flow works perfectly, but there are a number of warts.  OBD doesn't support recursive CFDIRECTORY so a number of things simply fail, including packaged classes.  It also doesn't handle all the Java numerics so if you do floating-point math in Groovy you may or may not get back a number you can use in CFML.

That said, if you checkout trunk from Subversion onto a OBD instance, you'll be able to run all the Groovy demos except "Simple Objects" (because of the numerics issue – java.math.BigDecimal specifically).  The Hibernate integration currently depends on packaged classes which OBD can't compile, but if I can get access to the datasource information as I can on CF and Railo, I think Hibernate will work as well.

Finally, I want to give a big shout out to my version control system.  The ability to go back and selectively revert individual changes in individual files from the past four months saved me hours and hours of headaches.  If you don't have version control set up for every line of code you write, stop reading right now and go do that.  Then you can come back and finish.

As always, source is available at https://ssl.barneyb.com/svn/barneyb/cfgroovy/trunk/demo.  That's the demo app, as you'd imagine from the URL, which includes the actual CFGroovy engine.

And no, no idea about Hibernate support.  That one is WAY more complicated.  : )

The integration of Hibernate all over the place is very exciting.  CF-based ORM tools suck, frankly.  Which isn't to belittle Mark or Doug in any way, they've done a fantastic job, it's problems with CF itself that are the issue.  With Railo's "CFC is a class" implementation, Hibernate is directly applicable.  With CF's crazy "a CFC is a bunch of classes in a Map" implementation, I'm not sure how Adobe's going to get it to work.  I'm very much hoping they fix the core issue (which would almost certainly give some nice performance benefits as well) instead of bastardizing Hibernate to get it to work, but we'll see.

Groovy has a number of advantages for this type of integration of JavaScript, the biggest one being that Groovy IS Java, and carries Java's semantics almost perfectly. So unlike with Rhino, no major conversions are needed moving in and out of Groovy, which makes things enormously easier. CF still brings it's special blend of "insane" to the party, but it works quite well overall. Definitely has more real-world potential than CF Rhino ever did.

CF Groovy is not a whole framework like CF Rhino was, it's really just a proof of concept for integrating the two together and sharing resources. You can get the demo (which includes the engine via svn:externals) from Subversion at https://ssl.barneyb.com/svn/barneyb/cfgroovy/trunk/demo/. Just check it out to a directory named 'cfgroovy' in your webroot, drop the groovy JAR from the 'groovyEngine' subdirectory into your /WEB-INF/lib folder, and you should be done.  You can see it in action at the demo page, though without source to browse, it's not very interesting.

Also, unlike CF Rhino, there's no dependencies on the internals of ColdFusion (the Adobe product). To do some of the bridging to JavaScript, I had to invoke internal APIs of ColdFusion, so it wouldn't run on BlueDragon, Railo, etc. I built CF Groovy with Open BlueDragon and Railo 3 on Tomcat simply because I didn't have a CFML runtime on my box, and CF is like 400MB while oBD is 11MB and Railo is 25MB.

Unfortunately, all three runtimes have bugs that prevent them from working as expected.

Railo was the worst: it has some recursion issue with the JEE.include() call. It also doesn't seem to implement java.util.Map with it's struct implementation, and throws on missing keys rather than returning null.

Open BlueDragon initializes ResultSets from manually assembled queries (and possibly "real" queries) with the row pointer pointed at the first row, rather than before the first row as the spec says it should be.

ColdFusion doesn't create java.util.Date objects with the createDate built in, so trying to call ResultSet.getDate() throws a ClassCastException. Using ResultSet.getObject() and letting the ducks work their magic fixes this issue. It's also 15-35 times larger than the others.

Except for the download size issue, I've got conditionals to cover all the cases in the app, so it should be checkout and run on all three platforms. I haven't tested NA BD, CF7-, or Railo 2. I don't know why they wouldn't work, though, since I'm just doing standard Java stuff. I'm not doing any version conditionals, only platform ones, just in case.

1)
I mistyped 'reqeustTimeout' [sic] in a CFSETTING tag.  BD didn't
complain, and I didn't catch it, because the extra time for the request
never happened to be needed, but CF threw a syntax error immediately.

2)
BD 6.2 puts the CFFILE result struct from uploads into local variable
(if declared), inside functions. I was never quite sure what CFMX 6 did
regarding this.  CF7, however, puts it in some unknown place
(presumably variables scope) that is shadowed by the local variable
scope.  Just a matter of adding the new CF7 'result' attribute to
name the value you want the result placed in.  I think this is
actually a bug in CF7 (breaking backwards compatibility), but I'm not
sure about that.  Either way, it is a difference between BD and CF
that you should watch out for.

1) BD doesn't care if your 'var' declared local variables are at the top of a function or not, while CFMX does.

2) BD considers assignment to be an expression, while CFMX doesn't.  In BD <cfreturn s = s & "text" /> is legal.

3)
BD processes CFLOGIN-based security stuff (at least when the
loginstorage is set to session) for all requests in a session that have
be logged in with CFLOGINUSER, regardless of whether CFLOGIN is
actually on every page.  In other words, on CFMX you have to have
CFLOGIN run on every page to use the cflogin framework, while on BD you
just have to have it run once per session.  Personally, I like
BD's interpretation, but all it takes is adding a self-closed CFLOGIN
tag right after your CFAPPLICATION tag to make it work on CFMX.

4)
BD doesn't seem to validate return types on CFFUNCTION quite all the
way.  I had a function with a numeric returnttype that returned
the result of a SELECT MAX(...) ... query, and when no rows were found,
the result of the MAX call is obviously null, which isn't numeric (and
yes, I'm going to restrain myself from that rant ;).  BD happily
let me return null from the method, but CFMX errored.  Perhaps
because BD actually recognized the null for what it is, and let it pass
the test?

I also ran into
some issues using JS remoting (via Neuromancer) against a CFC-based web
service.  I had a lot of issues with getting that all working on
BD when I first wrote the app, so I suspect I ended up implementing
some stuff that wasn't quite CFMX-compatible, but I can't say that with
conviction, so I left it off the list of definite bugs.  The fix
was simple to make, so I'm not going to worry about it.

So there they are, four (and a half) points to watch out for when
moving from BD to CFMX.  As I said above, I'm not bitter, because
in every case the issue arose because I made an honest mistake in
coding, and BD did what I meant without
throwing an error.  Of course, in every case, BD was incompatible
with CFMX, but I'm going to put that behind me.  So if you're
developing on BD and planning to deploy to CFMX, watch out for these
gotchas.  Catching them as you code isn't a big deal, but having
to sweep an app for this type of stuff at deploy-time would be a bear,
especially if it's large.  The first two are compile-time errors,
so they'll be caught easily, the third will be apparent as soon as you
try to log in, but the fourth will require careful unit testing to
catch, because it's a data-dependant runtime bug.

Of course, after the final 6.2 release, NA is dropping all support for
the RC, so you're better off upgrading sooner than later, but there
isn't the hard deadline to do so.

I'm excited to see what tweaks and fixes NA has made from the RC to the
final release (since this site and several others are running on the
pre-release version), but I'm a little concerned that the timeframe is
so tight to get the upgrade in.  Hopefully no code will break with
the new version, because there isn't going to be much time to fix it.

Next problem was doing some simple image manipulation with the ImageIO class (from javax.imageio). Nothing complex, just a simple read-scale-write operation to generate a thumbnail. However, BD pukes on the write part. From the stack trace on the NPE, it appeared that it was having trouble selecting which of the method versions (write is overloaded) to call, even though it was pretty clear cut (the one with a RenderedImage, a String, and a File). What's the solution for this case? You guessed it. Write a JSP page that does the exact same thing (except it works), and then call it with CFHTTP. Ooof.

I do tire of such hacks, and so once again, my pursuit of the CF license is in full swing. I just finished up some more work for Fusium (awaiting the check), and lined up another little project that should just about round out the two grand I need. Now if only I could be done and have the license today….