Comments on: CFGroovy in Forty Lines https://www.barneyb.com/barneyblog/2009/05/14/cfgroovy-in-forty-lines/ Thoughts, rants, and even some code from the mind of Barney Boisvert. Thu, 11 Sep 2014 09:58:12 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Henry Ho https://www.barneyb.com/barneyblog/2009/05/14/cfgroovy-in-forty-lines/comment-page-1/#comment-177763 Henry Ho Fri, 15 May 2009 20:16:26 +0000 http://www.barneyb.com/barneyblog/?p=945#comment-177763 Nice... learned something new! :) Nice… learned something new! :)

]]> By: barneyb https://www.barneyb.com/barneyblog/2009/05/14/cfgroovy-in-forty-lines/comment-page-1/#comment-177761 barneyb Fri, 15 May 2009 20:10:37 +0000 http://www.barneyb.com/barneyblog/?p=945#comment-177761 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. 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.

]]> By: Henry Ho https://www.barneyb.com/barneyblog/2009/05/14/cfgroovy-in-forty-lines/comment-page-1/#comment-177755 Henry Ho Fri, 15 May 2009 19:58:08 +0000 http://www.barneyb.com/barneyblog/?p=945#comment-177755 Just wondering... any advantage of using server["cfgroovy.scriptCache"] as java.util.HashMap instead of plain old CFML struct? Just wondering… any advantage of using server["cfgroovy.scriptCache"] as java.util.HashMap instead of plain old CFML struct?

]]> By: barneyb https://www.barneyb.com/barneyblog/2009/05/14/cfgroovy-in-forty-lines/comment-page-1/#comment-177610 barneyb Thu, 14 May 2009 15:41:36 +0000 http://www.barneyb.com/barneyblog/?p=945#comment-177610 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. 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.

]]> By: Joshua Frankamp https://www.barneyb.com/barneyblog/2009/05/14/cfgroovy-in-forty-lines/comment-page-1/#comment-177606 Joshua Frankamp Thu, 14 May 2009 15:19:59 +0000 http://www.barneyb.com/barneyblog/?p=945#comment-177606 Does this suffer from memory issues? I imagine not because of the single classloader, also no compilation... Does this suffer from memory issues? I imagine not because of the single classloader, also no compilation…

]]> By: Hal Helms https://www.barneyb.com/barneyblog/2009/05/14/cfgroovy-in-forty-lines/comment-page-1/#comment-177605 Hal Helms Thu, 14 May 2009 15:10:03 +0000 http://www.barneyb.com/barneyblog/?p=945#comment-177605 Nice, Barney. I agree with you about sacrificing backwards compatibility -- especially at this early stage. Look forward to seeing more! Nice, Barney. I agree with you about sacrificing backwards compatibility — especially at this early stage. Look forward to seeing more!

]]>