use of java 1.5

[Adam Heath-2]

I've noticed that ofbiz forces javac into 1.5 mode.  Then uses generics
in a *few* places thru-out the code.

Are there plans to make this more prevalent?

I've started work on doing that.  This work is two-fold; one, it helps
catch any casting issues.  Two, it's a code review.  I've actually found
logic errors(public Set keySet() { return this.keySet(); }) while adding
all the markup.

I know how ofbiz likes to have changes sent thru jira; but these patches
could touch alot of code.  Asking for write access might not be the
right approach, so I'm wondering what the best way to proceed would be.

==
adam@gradall:/job/ofbiz/ofbiz-svn/framework/base$ svk diff
src/base/|diffstat
...
 36 files changed, 743 insertions(+), 905 deletions(-)
adam@gradall:/job/ofbiz/ofbiz-svn/framework/base$ xclipboard
==

Things to note: UtilCache is now generified; so are classes in
util/collections.  I'm still going thru everything, but it goes quite
quickly.  I'm making certain that the external apis don't change either.

[Tim Ruppert]

Adam, these are super helpful changes where everyone would definitely benefit.  The process is definitely to send these thru JIRA, so please start to do that.  Put it in batches that make sense so that more than one person can help to tear thru them.

As David, sent along when Ean alluded to this earlier, we'd certainly welcome more committers, we just have to go thru the process 

Cheers,

Tim

--

Tim Ruppert

HotWax Media

http://www.hotwaxmedia.com

o:801.649.6594

f:801.649.6595

On Sep 13, 2007, at 12:00 AM, Adam Heath wrote:

I've noticed that ofbiz forces javac into 1.5 mode.  Then uses generics

in a *few* places thru-out the code.

Are there plans to make this more prevalent?

I've started work on doing that.  This work is two-fold; one, it helps

catch any casting issues.  Two, it's a code review.  I've actually found

logic errors(public Set keySet() { return this.keySet(); }) while adding

all the markup.

I know how ofbiz likes to have changes sent thru jira; but these patches

could touch alot of code.  Asking for write access might not be the

right approach, so I'm wondering what the best way to proceed would be.

==

adam@gradall:/job/ofbiz/ofbiz-svn/framework/base$ svk diff

src/base/|diffstat

...

 36 files changed, 743 insertions(+), 905 deletions(-)

adam@gradall:/job/ofbiz/ofbiz-svn/framework/base$ xclipboard

==

Things to note: UtilCache is now generified; so are classes in

util/collections.  I'm still going thru everything, but it goes quite

quickly.  I'm making certain that the external apis don't change either.

[Adrian Crum]

Adam Heath wrote:
> Things to note: UtilCache is now generified; so are classes in
> util/collections.

It would be cool if UtilCache implemented a basic cache interface, so that other classes can cache
their data in an implementation-safe manner - by implementing the same interface.

See the comment in ServiceEcaUtil.java, line 52. ServiceEcaUtil could have a contained class that
implements the cache interface so that the concerns mentioned in that comment could be addressed.

-Adrian

[Adam Heath-2]

Adrian Crum wrote:

> Adam Heath wrote:
>> Things to note: UtilCache is now generified; so are classes in
>> util/collections.
>
> It would be cool if UtilCache implemented a basic cache interface, so
> that other classes can cache their data in an implementation-safe manner
> - by implementing the same interface.
>
> See the comment in ServiceEcaUtil.java, line 52. ServiceEcaUtil could
> have a contained class that implements the cache interface so that the
> concerns mentioned in that comment could be addressed.

Ok, I read that, and the code that access ecaCache.  The comment makes
no sense, you would never want to use UtilCache here.

Now, if you are wanting some code of auto-building map, where a request
for a non-existant key builds the value automatically(with reference
handling, lru, disk serialization stuff handled too), then yes, that
would be useful.

But in ServiceEcaUtil, it wouldn't.  You'd have to change the component
stuff(probably, I'm not going to study that part again right this
moment) to make it a bit easier to access in piecemeal.

[Adrian Crum]

Adam Heath wrote:

> Adrian Crum wrote:
>
>>Adam Heath wrote:
>>
>>>Things to note: UtilCache is now generified; so are classes in
>>>util/collections.
>>
>>It would be cool if UtilCache implemented a basic cache interface, so
>>that other classes can cache their data in an implementation-safe manner
>>- by implementing the same interface.
>>
>>See the comment in ServiceEcaUtil.java, line 52. ServiceEcaUtil could
>>have a contained class that implements the cache interface so that the
>>concerns mentioned in that comment could be addressed.
>
>
> Ok, I read that, and the code that access ecaCache.  The comment makes
> no sense, you would never want to use UtilCache here.
>
> Now, if you are wanting some code of auto-building map, where a request
> for a non-existant key builds the value automatically(with reference
> handling, lru, disk serialization stuff handled too), then yes, that
> would be useful.
>
> But in ServiceEcaUtil, it wouldn't.  You'd have to change the component
> stuff(probably, I'm not going to study that part again right this
> moment) to make it a bit easier to access in piecemeal.

I wasn't suggesting using UtilCache - I was suggesting using a ServiceEcaUtil implementation of a
basic cache interface. When the interface's cache clear method is called, the ServiceEcaUtil
implementation of the interface would clear the Map, then reload the ECAs.

Other classes could do the same thing in the cases where using UtilCache would be dangerous or
undesirable.

[Adam Heath-2]

Adrian Crum wrote:
> I wasn't suggesting using UtilCache - I was suggesting using a
> ServiceEcaUtil implementation of a basic cache interface. When the
> interface's cache clear method is called, the ServiceEcaUtil
> implementation of the interface would clear the Map, then reload the ECAs.

Ah, yes, I understand that.

But you do not want a clear() call to automatically repopulate.  You
only repopulate when the item is needed again.  Otherwise, the original
clear call didn't really have any affect(ie, for reducing memory).

> Other classes could do the same thing in the cases where using UtilCache
> would be dangerous or undesirable.

Well, if the 'cache' user can always recreate the values from the given
key, it's not really a problem; just additional load.

For those who care, this kind of auto-create-value-base-on-key is called
autovivification; it's something I learned while working with perl.

[Adrian Crum]

Adam Heath wrote:

> Adrian Crum wrote:
>
>>I wasn't suggesting using UtilCache - I was suggesting using a
>>ServiceEcaUtil implementation of a basic cache interface. When the
>>interface's cache clear method is called, the ServiceEcaUtil
>>implementation of the interface would clear the Map, then reload the ECAs.
>
>
> Ah, yes, I understand that.
>
> But you do not want a clear() call to automatically repopulate.  You
> only repopulate when the item is needed again.  Otherwise, the original
> clear call didn't really have any affect(ie, for reducing memory).

Good point.

>>Other classes could do the same thing in the cases where using UtilCache
>>would be dangerous or undesirable.
>
>
> Well, if the 'cache' user can always recreate the values from the given
> key, it's not really a problem; just additional load.

I was thinking it would be helpful from the Webtools perspective. There are so many things cached in
memory that can't be cleared unless OFBiz is restarted. In my scenario, you could go to Webtools to
clear the ECA cache.

[David E Jones]

Adrian Crum wrote:
>> Well, if the 'cache' user can always recreate the values from the given
>> key, it's not really a problem; just additional load.
>
> I was thinking it would be helpful from the Webtools perspective. There
> are so many things cached in memory that can't be cleared unless OFBiz
> is restarted. In my scenario, you could go to Webtools to clear the ECA
> cache.

This is how it _should_ work, but the loading code needs to be refactored to reload it if it's not in the cache. That's how pretty much everything else works, it just needs to be done there. Then UtilCache can be used with a clear or timeout to reload just like we enjoy elsewhere.

-David

[Adrian Crum]

David E Jones wrote:

> Adrian Crum wrote:
>
>>> Well, if the 'cache' user can always recreate the values from the given
>>> key, it's not really a problem; just additional load.
>>
>>
>> I was thinking it would be helpful from the Webtools perspective.
>> There are so many things cached in memory that can't be cleared unless
>> OFBiz is restarted. In my scenario, you could go to Webtools to clear
>> the ECA cache.
>
>
> This is how it _should_ work, but the loading code needs to be
> refactored to reload it if it's not in the cache. That's how pretty much
> everything else works, it just needs to be done there. Then UtilCache
> can be used with a clear or timeout to reload just like we enjoy elsewhere.

True. I'll add "Refactor ECA loading to utilize UtilCache" to my list of things to do when I have
nothing else to do. ;-)