java 1.5 feature usage question

[Adam Heath-2]

How does everyone feel about using enums in ofbiz?  For pure java code,
they are a win.  For other code, that do something like:

==
myObject.someFunction(Constants.TYPE);
==

there shouldn't be any difference.  Once changed, instead of
Constants.TYPE being an int, or a String, it's a class that extends
Enum, so a recompile should be all that is nescessary.  And using enums
will ensure that an invalid int(or whatever) can't be passed.

[Tim Ruppert]

Personally, I'm a fan of any compile time checking :)

Cheers,

Tim

--

Tim Ruppert

HotWax Media

http://www.hotwaxmedia.com

o:801.649.6594

f:801.649.6595

On Oct 14, 2007, at 7:21 PM, Adam Heath wrote:

How does everyone feel about using enums in ofbiz?  For pure java code,

they are a win.  For other code, that do something like:

==

myObject.someFunction(Constants.TYPE);

==

there shouldn't be any difference.  Once changed, instead of

Constants.TYPE being an int, or a String, it's a class that extends

Enum, so a recompile should be all that is nescessary.  And using enums

will ensure that an invalid int(or whatever) can't be passed.

[Jacques Le Roux]

+1

Jacques
  ----- Message d'origine -----
  De : Tim Ruppert
  À : [hidden email]
  Envoyé : lundi 15 octobre 2007 04:58
  Objet : Re: java 1.5 feature usage question


  Personally, I'm a fan of any compile time checking :)



  Cheers,
  Tim
  --
  Tim Ruppert
  HotWax Media
  http://www.hotwaxmedia.com


  o:801.649.6594
  f:801.649.6595




  On Oct 14, 2007, at 7:21 PM, Adam Heath wrote:


    How does everyone feel about using enums in ofbiz?  For pure java code,
    they are a win.  For other code, that do something like:


    ==
    myObject.someFunction(Constants.TYPE);
    ==


    there shouldn't be any difference.  Once changed, instead of
    Constants.TYPE being an int, or a String, it's a class that extends
    Enum, so a recompile should be all that is nescessary.  And using enums
    will ensure that an invalid int(or whatever) can't be passed.

[Ray Barlow]

I agree the earlier you catch possible errors the better.

Ray


Tim Ruppert wrote:

> Personally, I'm a fan of any compile time checking :)
>
> Cheers,
> Tim
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
>
> On Oct 14, 2007, at 7:21 PM, Adam Heath wrote:
>
>> How does everyone feel about using enums in ofbiz?  For pure java code,
>> they are a win.  For other code, that do something like:
>>
>> ==
>> myObject.someFunction(Constants.TYPE);
>> ==
>>
>> there shouldn't be any difference.  Once changed, instead of
>> Constants.TYPE being an int, or a String, it's a class that extends
>> Enum, so a recompile should be all that is nescessary.  And using enums
>> will ensure that an invalid int(or whatever) can't be passed.
>

[jonwimp]

Nice. Back to C/C++ enums. But seems like it's much more.

Will BSH codes be able to use that too?

Enums in general are usually int (save space). It's often annoying when some rogue codes attempt
to pass in raw int(s) that do not correspond to any known/programmed enums. So, yes, using Java
1.5 enum is nice.

Jonathon

Adam Heath wrote:

> How does everyone feel about using enums in ofbiz?  For pure java code,
> they are a win.  For other code, that do something like:
>
> ==
> myObject.someFunction(Constants.TYPE);
> ==
>
> there shouldn't be any difference.  Once changed, instead of
> Constants.TYPE being an int, or a String, it's a class that extends
> Enum, so a recompile should be all that is nescessary.  And using enums
> will ensure that an invalid int(or whatever) can't be passed.
>
>

[Adam Heath-2]

Jonathon -- Improov wrote:

> Will BSH codes be able to use that too?

Our web framework(not in ofbiz) event languages, which uses janino and
groovy, work with our enums fine.  As far as they are concerned, they
look just like static class instances.

Plus, we get to use fancy EnumMap and EnumSet; the former is done as an
array, the latter as a bit set.

[Tim Ruppert]

I'm way into seeing groovy included - what's the license on that?

Cheers,

Tim

--

Tim Ruppert

HotWax Media

http://www.hotwaxmedia.com

o:801.649.6594

f:801.649.6595

On Oct 15, 2007, at 8:37 PM, Adam Heath wrote:

Jonathon -- Improov wrote:

Will BSH codes be able to use that too?

Our web framework(not in ofbiz) event languages, which uses janino and

groovy, work with our enums fine.  As far as they are concerned, they

look just like static class instances.

Plus, we get to use fancy EnumMap and EnumSet; the former is done as an

array, the latter as a bit set.

[Adam Heath-2]

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.

[David E Jones]

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!

-David

[Adam Heath-2]

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.