David E Jones wrote:
> On Oct 15, 2007, at 10:27 PM, Adam Heath wrote:
>
>> Tim Ruppert wrote:
>>> I'm way into seeing groovy included - what's the license on that?
>>
>> http://svn.codehaus.org/groovy/trunk/groovy/groovy-core/LICENSE.txt
>>
>> Which mentions APL 2.0. So, perfect.
>>
>> I wrote caching implementations of janino(java), bsh, groovy,
>> rhino(javascript), quercus(php), and jruby(ruby), extended bsf to
>> support faster loading(but I plan on redoing that, so it doesn't require
>> any bsf changes).
>>
>> So, ofbiz just needs better bsf integration, and you can get groovy for
>> free. Locally, we can already use groovy files for services.
>
> Yeah, that's cool Adam. This is definitely something we want in the
> project.
>
> I don't think we want to have any Groovy code aside from examples in
> OFBiz, but support for it is excellent. Basically we don't want to force
> people to learn a bunch of different scripting languages and other
> optional tools, but we certainly want to make it possible and easy to
> use them if that is what a group using OFBiz prefers!
Groovy is as fast as java, and is a simpler syntax; this has been our
experience. The native map syntax is so much simpler, and treating maps
as objects with properties is way faster.
==
def myMap = [fieldOne: "value", fieldTwo: 1.2345, timeStamp: new
Timestamp("...")]
System.err.println(myMap.fieldOne)
System.err.println(myMap.timeStamp)
myMap.newField = true
myMap.somethingElse = String.class
==
Plus other groovy(sic) things. Best to read the website.
With my caching bsf engines, I did speed tests. Pure java was always
fastest. groovy/rhino/php were equivalent. However, rhino/php had
integration issues with java(mostly with overloaded methods), and rhino
liked to wrap/unwrap java objects into it's own. groovy was a very
close match to existing java-think.
ps: I didn't test bsh at the time, I need to get back to that.
