jdk 1.5 or 1.6

[David E. Jones-2]

There are some API things that are better in 1.6, and not compatible with the 1.5 API, but they all seem to have some sort of work around. For some of those things we'll get better performance and maybe better flexibility (and maybe less code to maintain) if we use the 1.6 API.

IMO the biggest reason to require 1.6 is that some of the libraries we use are starting to require 1.6 for their newer versions, and chances are that will happen more over time. In other words, sooner or later we'll want to update something and they won't offer a 1.5 compatible alternative any more.

-David


On Nov 23, 2009, at 2:16 PM, Scott Gray wrote:

> I'm not necessarily against it but I'm yet to hear what we actually gain by doing so, what are these changes that we could optionally make once we stop supporting 1.5?  With the change from 1.4 to 1.5 it was pretty clear because of things like generics.
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 24/11/2009, at 9:49 AM, David E Jones wrote:
>
>>
>> OFBiz already runs fine on 1.6, so this would just be a matter of updating documentation and such, and then people could optionally make changes that require 1.6.
>>
>> If everyone is in favour of this, we might as well get a vote going...
>>
>> -David
>>
>>
>> On Nov 23, 2009, at 11:20 AM, Erwan de FERRIERES wrote:
>>
>>> +1
>>>
>>> Furthermore, on a debian lenny server, there is no jdk 1.5 in the repository...
>>>
>>> So, in order to make this migration, what are the required steps ? How can we divide the work to be done ?
>>>
>>> Cheers
>>>
>>> Le 14/11/2009 05:44, Tim Ruppert a écrit :
>>> ../..
>>>
>>> --
>>> Erwan
>>
>

[Adam Heath-2]

Adam Heath wrote:
> Scott Gray wrote:
>> I'm not necessarily against it but I'm yet to hear what we actually gain
>> by doing so, what are these changes that we could optionally make once
>> we stop supporting 1.5?  With the change from 1.4 to 1.5 it was pretty
>> clear because of things like generics.
>
> NavigablMap, which is implemented by ConcurrentSkipListMap, which
> provides for sorted concurrent maps.

In case I wasn't clear:

+1^infinity for java 1.6

[Scott Gray-2]

Yeah +1 from me, I just wanted to make sure we had some tangible  
benefits in mind and I didn't really see the dbcp library problem we  
had as being a good reason for the switch since it was easily resolved.

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 27/11/2009, at 11:49 AM, Adam Heath wrote:

> Adam Heath wrote:
>> Scott Gray wrote:
>>> I'm not necessarily against it but I'm yet to hear what we  
>>> actually gain
>>> by doing so, what are these changes that we could optionally make  
>>> once
>>> we stop supporting 1.5?  With the change from 1.4 to 1.5 it was  
>>> pretty
>>> clear because of things like generics.
>>
>> NavigablMap, which is implemented by ConcurrentSkipListMap, which
>> provides for sorted concurrent maps.
>
> In case I wasn't clear:
>
> +1^infinity for java 1.6
>

[Adam Heath-2]

Scott Gray wrote:
> Yeah +1 from me, I just wanted to make sure we had some tangible
> benefits in mind and I didn't really see the dbcp library problem we had
> as being a good reason for the switch since it was easily resolved.

Plus 1.6 hotspot is wicked smarter, and faster.
==
void foo() {
        Object[] array = new Object[6];
        ...
        bar(array);
        ...
        return
}

void bar(Object[] array) {
        System.err.println(Arrays.toString(array));
}
==

Before java 1.6, array would be allocated on the heap, which requires
cross-thread locking, to ensure consistency.

In java 1.6, after appropriate jitting, it can detect that array never
leaves the any of the method scopes, so actually converts it to
allocate *on the stack*.  This means allocation and the eventual
deallocation is *wicked* fast.

This feature is called escape analysis.

[Jacques Le Roux]

From: "Adam Heath" <[hidden email]>

> Scott Gray wrote:
>> Yeah +1 from me, I just wanted to make sure we had some tangible
>> benefits in mind and I didn't really see the dbcp library problem we had
>> as being a good reason for the switch since it was easily resolved.
>
> Plus 1.6 hotspot is wicked smarter, and faster.
> ==
> void foo() {
> Object[] array = new Object[6];
> ...
> bar(array);
> ...
> return
> }
>
> void bar(Object[] array) {
> System.err.println(Arrays.toString(array));
> }
> ==
>
> Before java 1.6, array would be allocated on the heap, which requires
> cross-thread locking, to ensure consistency.
>
> In java 1.6, after appropriate jitting, it can detect that array never
> leaves the any of the method scopes, so actually converts it to
> allocate *on the stack*.  This means allocation and the eventual
> deallocation is *wicked* fast.
>
> This feature is called escape analysis.

Interesting !

Thanks

Jacques

[Scott Gray-2]

On 27/11/2009, at 12:06 PM, Adam Heath wrote:

> Scott Gray wrote:
>> Yeah +1 from me, I just wanted to make sure we had some tangible
>> benefits in mind and I didn't really see the dbcp library problem  
>> we had
>> as being a good reason for the switch since it was easily resolved.
>
> Plus 1.6 hotspot is wicked smarter, and faster.

These sorts of improvements are available right now simply by running  
OFBiz on 1.6 though right?

> ==
> void foo() {
> Object[] array = new Object[6];
> ...
> bar(array);
> ...
> return
> }
>
> void bar(Object[] array) {
> System.err.println(Arrays.toString(array));
> }
> ==
>
> Before java 1.6, array would be allocated on the heap, which requires
> cross-thread locking, to ensure consistency.
>
> In java 1.6, after appropriate jitting, it can detect that array never
> leaves the any of the method scopes, so actually converts it to
> allocate *on the stack*.  This means allocation and the eventual
> deallocation is *wicked* fast.
>
> This feature is called escape analysis.

[Jacques Le Roux]

From: "Scott Gray" <[hidden email]>

> On 27/11/2009, at 12:06 PM, Adam Heath wrote:
>
>> Scott Gray wrote:
>>> Yeah +1 from me, I just wanted to make sure we had some tangible
>>> benefits in mind and I didn't really see the dbcp library problem  we had
>>> as being a good reason for the switch since it was easily resolved.
>>
>> Plus 1.6 hotspot is wicked smarter, and faster.
>
> These sorts of improvements are available right now simply by running  OFBiz on 1.6 though right?

Yes.

1) I proposed initially jdk 1.6 move because of the DBCP issue. I agree now with Scott. Maybe we can wait to be in a situation that
really forces us to move ahead. It's simply pragmatic: why working on an issue that does not exist yet? Even if we are sure we will
cross them.

2) I don't care about Cloudscape, 0 for me. Though yes why not clean up things a bit  ? So 0.001 :o)

3) On the Workflow/Shark components issue, we could have the same attitude. We crossed an issue we know that will come again. Scott
proposed to handle it (the problems comes from generating Shark Javadoc, we can disable it -Workflow too - as we currently disable
Shark and Workflow compilations). Moreover I suggested to move them in a new deprecated directories just under root but disconnected
from current work. We would isolate there as well all deprecated components in the future. There they will be easy to spot. And if
we put
special directions on how to use them (like we have currently in OPTIONNAL_LIBRARIES for Shark) we would not have to care about them
anymore. If someone want to use/improve them: fell free...

Birt will be integrated soon, I think we all agree. For now, as Scott said, licence issues are a no no.
Fell free to update Junit.

I would say: let's be pragmatic, we have enough interesting other things to do...

Jacques

[Scott Gray-2]

On 27/11/2009, at 8:12 PM, Jacques Le Roux wrote:

> From: "Scott Gray" <[hidden email]>
>> On 27/11/2009, at 12:06 PM, Adam Heath wrote:
>>
>>> Scott Gray wrote:
>>>> Yeah +1 from me, I just wanted to make sure we had some tangible
>>>> benefits in mind and I didn't really see the dbcp library  
>>>> problem  we had
>>>> as being a good reason for the switch since it was easily resolved.
>>>
>>> Plus 1.6 hotspot is wicked smarter, and faster.
>>
>> These sorts of improvements are available right now simply by  
>> running  OFBiz on 1.6 though right?
>
> Yes.
>
> 1) I proposed initially jdk 1.6 move because of the DBCP issue. I  
> agree now with Scott. Maybe we can wait to be in a situation that
> really forces us to move ahead. It's simply pragmatic: why working  
> on an issue that does not exist yet? Even if we are sure we will
> cross them.

Stir up the hornet's nest and then change your mind :-)
I was never against the change, I just wanted to clarify the reasoning  
for making it.  Because 1.5 isn't holding back anything I am trying to  
do it doesn't bother me to support it but if other committers feel  
that it holding back good changes then I am favor of accommodating them.

I just sent an email regarding the other stuff so I won't repeat it  
here.

> 2) I don't care about Cloudscape, 0 for me. Though yes why not clean  
> up things a bit  ? So 0.001 :o)
>
> 3) On the Workflow/Shark components issue, we could have the same  
> attitude. We crossed an issue we know that will come again. Scott
> proposed to handle it (the problems comes from generating Shark  
> Javadoc, we can disable it -Workflow too - as we currently disable
> Shark and Workflow compilations). Moreover I suggested to move them  
> in a new deprecated directories just under root but disconnected
> from current work. We would isolate there as well all deprecated  
> components in the future. There they will be easy to spot. And if we  
> put
> special directions on how to use them (like we have currently in  
> OPTIONNAL_LIBRARIES for Shark) we would not have to care about them
> anymore. If someone want to use/improve them: fell free...
>
> Birt will be integrated soon, I think we all agree. For now, as  
> Scott said, licence issues are a no no.
> Fell free to update Junit.
>
> I would say: let's be pragmatic, we have enough interesting other  
> things to do...
>
> Jacques
>
>

[Adam Heath-2]

Jacques Le Roux wrote:
> 1) I proposed initially jdk 1.6 move because of the DBCP issue. I agree
> now with Scott. Maybe we can wait to be in a situation that
> really forces us to move ahead. It's simply pragmatic: why working on an
> issue that does not exist yet? Even if we are sure we will
> cross them.

I'm working on a major UtilCache update, one that takes full advantage
of java.util.concurrent, non-blocking, and java 1.6.  I've got it
mostly ready to go, just working on test cases(which will take a bit,
as threaded test cases are complex).

> 3) On the Workflow/Shark components issue, we could have the same
> attitude. We crossed an issue we know that will come again. Scott
> proposed to handle it (the problems comes from generating Shark Javadoc,
> we can disable it -Workflow too - as we currently disable
> Shark and Workflow compilations). Moreover I suggested to move them in a
> new deprecated directories just under root but disconnected
> from current work. We would isolate there as well all deprecated
> components in the future. There they will be easy to spot. And if we put
> special directions on how to use them (like we have currently in
> OPTIONNAL_LIBRARIES for Shark) we would not have to care about them
> anymore. If someone want to use/improve them: fell free...

If no one takes ownership of the shark code, then we shouldn't keep it
in the project.

For those parts of ofbiz that require external,
non-apache-redistributable libraries, if no one is available to keep
the code working, then the burden becomes too high.

> Birt will be integrated soon, I think we all agree. For now, as Scott
> said, licence issues are a no no.

Birt should have never been added as a branch into the primary, main,
central, shared repository.  It should have been done external, until
these issues were resolved.  Any large, external project with it's own
set of required libraries should be done much more carefully.
Licensing issues need to be fixed *before* they are added into svn
history, which is maintained until the end of time.