java 1.5 additions

[Adam Heath <do...@brainfood.com>]

Last week, I asked about whether using java 1.5 features was allowed;
the response I got was ok.  So, I've gone to town, adding lots of stuff
to the framework code.  While doing so, I've come upon a few questions I
need to ask.

First, what is the policy on read-only maps?  The entity and service
engines take incoming maps in several places(conditions, runSync, etc).
 Who owns the map when in those cases?  If I create a condition with a
map, or call a service with the map, is the ofbiz code allowed to modify
the map passed in?  The generics markup has a feature that allows me to
effectively mark a collection as read-only(can't put values into it, but
*can* remove items from it, or fetch values).

Second, I've noticed a rather critical bug.  When I extended the entity
cache years ago, I added a feature that would remove cached Lists of
GenericValue(List<GenericValue>) from UtilCache.  This was done by
iterating the values in the cache table, and calling it.remove().
Calling remove is supposed to remove the item from the cached entry.

However, when UtilCache was extended to support storing values on disk,
the iterator returned by getCacheLineValues() is a copy; calling
it.remove() on the collection does *not* remove the item from the
backing store.

ps: My work continues on adding java 1.5 features to ofbiz.  I'm adding
generics markup to all of framework/.  I'm also using enhanced for
loops, Integer.valueOf(in place of parseInt), auto-boxing,
StringBuilder, etc).

==
adam@gradall:/job/ofbiz/ofbiz-svn$ svk diff
/job/ofbiz/ofbiz-svn/framework|diffstat|tail -n1
 215 files changed, 4046 insertions(+), 4786 deletions(-)
==

pps: While doing this work, I'm also doing what amounts to a code
review; as such, I have found several logic bugs(one I have already
mentioned).  I'll start sending some of those issues tomorrow.

Re: java 1.5 additions

[Jacques Le Roux <ja...@les7arts.com>]

Yes this is really a good new.

There are already many issues pending. We try to do our best. Making issues easier for committers to review and test is really
appreciated.

Thanks

Jacques

De : "Jacopo Cappellato" <ti...@sastau.it>
> Hi Adam,
>
> Adam Heath wrote:
> > ...
> >
> > ps: My work continues on adding java 1.5 features to ofbiz.  I'm adding
> > generics markup to all of framework/.  I'm also using enhanced for
> > loops, Integer.valueOf(in place of parseInt), auto-boxing,
> > StringBuilder, etc).
> >
>   > pps: While doing this work, I'm also doing what amounts to a code
> > review; as such, I have found several logic bugs(one I have already
> > mentioned).  I'll start sending some of those issues tomorrow.
>
> this is good news.
> Please, create independent and separate issues (as much as possible)for
> each of the tasks you are working on; they will be easier to
> review/comment/commit and it will be possible some early feedback on them.
>
> Thanks,
>
> Jacopo
>
>

Re: java 1.5 additions

[Adam Heath <do...@brainfood.com>]

Jacopo Cappellato wrote:
> Hi Adam,
> 
> Adam Heath wrote:
>> ...
>>
>> ps: My work continues on adding java 1.5 features to ofbiz.  I'm adding
>> generics markup to all of framework/.  I'm also using enhanced for
>> loops, Integer.valueOf(in place of parseInt), auto-boxing,
>> StringBuilder, etc).
>>
>  > pps: While doing this work, I'm also doing what amounts to a code
>> review; as such, I have found several logic bugs(one I have already
>> mentioned).  I'll start sending some of those issues tomorrow.
> 
> this is good news.
> Please, create independent and separate issues (as much as possible)for
> each of the tasks you are working on; they will be easier to
> review/comment/commit and it will be possible some early feedback on them.

Right now, it's a bit hard; after I modify some base class, then compile
some other part of ofbiz, I find I need to alter how I've done the
genericising.

Segments I've completed so far: base, entity, service, and everything
inbetween.  Basically, the standard order used during a normal compile.
 I have *not* yet run this code, nor run the test cases.

Re: java 1.5 additions

[Jacopo Cappellato <ti...@sastau.it>]

Hi Adam,

Adam Heath wrote:
> ...
> 
> ps: My work continues on adding java 1.5 features to ofbiz.  I'm adding
> generics markup to all of framework/.  I'm also using enhanced for
> loops, Integer.valueOf(in place of parseInt), auto-boxing,
> StringBuilder, etc).
> 
  > pps: While doing this work, I'm also doing what amounts to a code
> review; as such, I have found several logic bugs(one I have already
> mentioned).  I'll start sending some of those issues tomorrow.

this is good news.
Please, create independent and separate issues (as much as possible)for 
each of the tasks you are working on; they will be easier to 
review/comment/commit and it will be possible some early feedback on them.

Thanks,

Jacopo

Re: java 1.5 additions

[Tim Ruppert <ti...@hotwaxmedia.com>]

Adam, this amount of working thru everything is going to be a HUGE  
win for OFBiz IMHO.  My only recommendation is to start submitting  
them in SMALL batches.  No one is going to go thru a 20K patch file  
and be certain of ANYTHING that happened.  And without more tests on  
this code base - it's going to intimidate even the most savvy.

Please do what you can to break it up so that more people can look at  
individual parts.

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

o:801.649.6594
f:801.649.6595


On Sep 22, 2007, at 4:03 PM, Adam Heath wrote:

> Last week, I asked about whether using java 1.5 features was allowed;
> the response I got was ok.  So, I've gone to town, adding lots of  
> stuff
> to the framework code.  While doing so, I've come upon a few  
> questions I
> need to ask.
>
> First, what is the policy on read-only maps?  The entity and service
> engines take incoming maps in several places(conditions, runSync,  
> etc).
>  Who owns the map when in those cases?  If I create a condition with a
> map, or call a service with the map, is the ofbiz code allowed to  
> modify
> the map passed in?  The generics markup has a feature that allows  
> me to
> effectively mark a collection as read-only(can't put values into  
> it, but
> *can* remove items from it, or fetch values).
>
> Second, I've noticed a rather critical bug.  When I extended the  
> entity
> cache years ago, I added a feature that would remove cached Lists of
> GenericValue(List<GenericValue>) from UtilCache.  This was done by
> iterating the values in the cache table, and calling it.remove().
> Calling remove is supposed to remove the item from the cached entry.
>
> However, when UtilCache was extended to support storing values on  
> disk,
> the iterator returned by getCacheLineValues() is a copy; calling
> it.remove() on the collection does *not* remove the item from the
> backing store.
>
> ps: My work continues on adding java 1.5 features to ofbiz.  I'm  
> adding
> generics markup to all of framework/.  I'm also using enhanced for
> loops, Integer.valueOf(in place of parseInt), auto-boxing,
> StringBuilder, etc).
>
> ==
> adam@gradall:/job/ofbiz/ofbiz-svn$ svk diff
> /job/ofbiz/ofbiz-svn/framework|diffstat|tail -n1
>  215 files changed, 4046 insertions(+), 4786 deletions(-)
> ==
>
> pps: While doing this work, I'm also doing what amounts to a code
> review; as such, I have found several logic bugs(one I have already
> mentioned).  I'll start sending some of those issues tomorrow.