It's been a couple months since I've done anything with CFGroovy. I've been mulling how to get back to the essence, which is Groovy scriptlets in CFML. Today at cf.objective() I put my fingers back on the keyboard for the first time. Here's a full implementation of the
It does depend on having Groovy already available on your classpath (one of those missing bells and whistles is auto-loading Groovy). This is the first version of the CFGroovy 2 line, which I've decided will be a ground-up rewrite. Backwards compatibility is a goal, and I think it's a reasonable one, but where CFGroovy 1.0 was developed with an application focus, CFGroovy 2.0 will be developed with an architecture focus. If you liked this write-up and you would like to acquire far more information https://climatex.org/exxonmobilerewardsplus/ to find out more. I'm willing to sacrifice a little backwards compatibility, particularly with Hibernate integration, to attain that.
Nice, Barney. I agree with you about sacrificing backwards compatibility — especially at this early stage. Look forward to seeing more!
Does this suffer from memory issues? I imagine not because of the single classloader, also no compilation…
Joshua,
It theory it has an unbounded memory footprint, but in reality it's pretty tight. A single instance of the loader, along with a Class for each distinct script executed. If you have a huge number of scripts (for instance if you use CFML interpolation to dynamically create them) you could potentially have issues, but that's about it. Nothing like the dynamic ClassLoader instantiation penalty or the memory leak bug we ran into.
Just wondering… any advantage of using server["cfgroovy.scriptCache"] as java.util.HashMap instead of plain old CFML struct?
Primarily case sensitivity. Groovy is case sensitive, so a script "myArray = []" and a script "myarray = []" are different to Groovy. A CF struct wouldn't differentiate between the two, since I'm using the script text itself as the key.
Nice… learned something new! :)