JDK 1.5 new features

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

JDK 1.5 new features

Jacques Le Roux
Administrator
Hi Developpers,

Now that JDK 1.5 is no longer a problem I propose to vote on using 1.5 new features. What do you think ?

Jacques
Reply | Threaded
Open this post in threaded view
|

Re: JDK 1.5 new features

Andrew Sykes
Jacques,

What features do you have in mind?

Stuff like autoboxing and foreach loops would probably reduce the
overall code size, but would also stop people from using an older JDK.

Removing support for 1.4x might mean people's proprietary modifications
or libraries cease to be compatible.

Are you suggesting this change for existing code or new code?


On Tue, 2006-10-03 at 07:56 +0200, Jacques Le Roux wrote:
> Hi Developpers,
>
> Now that JDK 1.5 is no longer a problem I propose to vote on using 1.5 new features. What do you think ?
>
> Jacques
--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

Reply | Threaded
Open this post in threaded view
|

Re: JDK 1.5 new features

Jacques Le Roux
Administrator
Hi Andrew,

My comments inline.

From: "Andrew Sykes" <[hidden email]>
> Jacques,
>
> What features do you have in mind?

C# like (notably foreach like loops but also autoboxing, enum type and  varargs)
For more please see : http://java.sun.com/j2se/1.5.0/docs/guide/language/index.html

> Stuff like autoboxing and foreach loops would probably reduce the
> overall code size, but would also stop people from using an older JDK.

Yes, one day or another we will have to do it anyway, why waiting ?
It's not difficult to switch from 1.4 to 1.5.
They are some bugs solved (notably this one which was annoying in POS (block debugging in Eclipse, ok in NetBeans) :
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6330496)
And last but not least it's faster :o)

> Removing support for 1.4x might mean people's proprietary modifications
> or libraries cease to be compatible.

Yes that's might be a *problem*. Are you already aware of such cases (or anybody else of course) ?

> Are you suggesting this change for existing code or new code?

I was thinking primarily at new code. When refactoring old code (bug, improvements, etc.) 1.5 new features may be also used.

Jacques

>
> On Tue, 2006-10-03 at 07:56 +0200, Jacques Le Roux wrote:
> > Hi Developpers,
> >
> > Now that JDK 1.5 is no longer a problem I propose to vote on using 1.5 new features. What do you think ?
> >
> > Jacques

Reply | Threaded
Open this post in threaded view
|

Re: JDK 1.5 new features

Andrew Sykes
Jacques,

My concern would be that once you introduce these features the code is
no longer going to compile unless you use 1.5

I remember there was a big problem for us between 1.3 and 1.4 because
the WorldPay libs we were using were not compatible with 1.4.
Fortunately we were able to just continue using 1.3 for a while, but of
course that would have been a real problem if there was suddenly
incompatible code.

I don't know of any issues like this with 1.5, but I'd hate to discover
one 5 minutes before home time on a Friday! Hence my cautious attitude.

Perhaps we could introduce a single 1.5 code instance somewhere which
would enforce an upgrade. This would mean that we could watch for
feedback on the ML for a while and offer an easy fix for anyone who was
experiencing problems.

Alternatively perhaps it would be a good idea to wait until the upcoming
release, then if someone has problems, they can simply revert to that
release.

What do you think?

You make an interesting point about speed, I've not run ofbiz with 1.5
yet - is it noticeably faster?

-Andrew

On Tue, 2006-10-03 at 11:40 +0200, Jacques Le Roux wrote:

> Hi Andrew,
>
> My comments inline.
>
> From: "Andrew Sykes" <[hidden email]>
> > Jacques,
> >
> > What features do you have in mind?
>
> C# like (notably foreach like loops but also autoboxing, enum type and  varargs)
> For more please see : http://java.sun.com/j2se/1.5.0/docs/guide/language/index.html
>
> > Stuff like autoboxing and foreach loops would probably reduce the
> > overall code size, but would also stop people from using an older JDK.
>
> Yes, one day or another we will have to do it anyway, why waiting ?
> It's not difficult to switch from 1.4 to 1.5.
> They are some bugs solved (notably this one which was annoying in POS (block debugging in Eclipse, ok in NetBeans) :
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6330496)
> And last but not least it's faster :o)
>
> > Removing support for 1.4x might mean people's proprietary modifications
> > or libraries cease to be compatible.
>
> Yes that's might be a *problem*. Are you already aware of such cases (or anybody else of course) ?
>
> > Are you suggesting this change for existing code or new code?
>
> I was thinking primarily at new code. When refactoring old code (bug, improvements, etc.) 1.5 new features may be also used.
>
> Jacques
>
> >
> > On Tue, 2006-10-03 at 07:56 +0200, Jacques Le Roux wrote:
> > > Hi Developpers,
> > >
> > > Now that JDK 1.5 is no longer a problem I propose to vote on using 1.5 new features. What do you think ?
> > >
> > > Jacques
>
--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

Reply | Threaded
Open this post in threaded view
|

Re: JDK 1.5 new features

Jacques Le Roux
Administrator
Andrew,

I understand your position (indeed we have enough problems to solve). Let's see what others think...

Perhaps a solution : http://retroweaver.sourceforge.net/
Though if you have not the souce code and only jars this is not a solution :(

What Sun says : http://java.sun.com/javase/technologies/compatibility.jsp (sources shouln'd be a problem)

Using release mechanism for such a change is surely a good idea.

Yes it's a little bit faster, on POS it's significant (I think because of the bug I reported below)

Jacques

From: "Andrew Sykes" <[hidden email]>

> Jacques,
>
> My concern would be that once you introduce these features the code is
> no longer going to compile unless you use 1.5
>
> I remember there was a big problem for us between 1.3 and 1.4 because
> the WorldPay libs we were using were not compatible with 1.4.
> Fortunately we were able to just continue using 1.3 for a while, but of
> course that would have been a real problem if there was suddenly
> incompatible code.
>
> I don't know of any issues like this with 1.5, but I'd hate to discover
> one 5 minutes before home time on a Friday! Hence my cautious attitude.
>
> Perhaps we could introduce a single 1.5 code instance somewhere which
> would enforce an upgrade. This would mean that we could watch for
> feedback on the ML for a while and offer an easy fix for anyone who was
> experiencing problems.
>
> Alternatively perhaps it would be a good idea to wait until the upcoming
> release, then if someone has problems, they can simply revert to that
> release.
>
> What do you think?
>
> You make an interesting point about speed, I've not run ofbiz with 1.5
> yet - is it noticeably faster?
>
> -Andrew
>
> On Tue, 2006-10-03 at 11:40 +0200, Jacques Le Roux wrote:
> > Hi Andrew,
> >
> > My comments inline.
> >
> > From: "Andrew Sykes" <[hidden email]>
> > > Jacques,
> > >
> > > What features do you have in mind?
> >
> > C# like (notably foreach like loops but also autoboxing, enum type and  varargs)
> > For more please see : http://java.sun.com/j2se/1.5.0/docs/guide/language/index.html
> >
> > > Stuff like autoboxing and foreach loops would probably reduce the
> > > overall code size, but would also stop people from using an older JDK.
> >
> > Yes, one day or another we will have to do it anyway, why waiting ?
> > It's not difficult to switch from 1.4 to 1.5.
> > They are some bugs solved (notably this one which was annoying in POS (block debugging in Eclipse, ok in NetBeans) :
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6330496)
> > And last but not least it's faster :o)
> >
> > > Removing support for 1.4x might mean people's proprietary modifications
> > > or libraries cease to be compatible.
> >
> > Yes that's might be a *problem*. Are you already aware of such cases (or anybody else of course) ?
> >
> > > Are you suggesting this change for existing code or new code?
> >
> > I was thinking primarily at new code. When refactoring old code (bug, improvements, etc.) 1.5 new features may be also used.
> >
> > Jacques
> >
> > >
> > > On Tue, 2006-10-03 at 07:56 +0200, Jacques Le Roux wrote:
> > > > Hi Developpers,
> > > >
> > > > Now that JDK 1.5 is no longer a problem I propose to vote on using 1.5 new features. What do you think ?
> > > >
> > > > Jacques
> >
> --
> Kind Regards
> Andrew Sykes <[hidden email]>
> Sykes Development Ltd
> http://www.sykesdevelopment.com
Reply | Threaded
Open this post in threaded view
|

Re: JDK 1.5 new features

Andrew Sykes
Jacques,

My last point on the subject, ideally I think this should be started
after a release, because that way if anyone runs into problems, they at
least have a relatively stable version to work with.

It would be a shame to lose a new recruit because they needed some
unrelated 1.4 lib.

If it's started before the release that wouldn't be an option.

 - Andrew

On Tue, 2006-10-03 at 13:49 +0200, Jacques Le Roux wrote:

> Andrew,
>
> I understand your position (indeed we have enough problems to solve). Let's see what others think...
>
> Perhaps a solution : http://retroweaver.sourceforge.net/
> Though if you have not the souce code and only jars this is not a solution :(
>
> What Sun says : http://java.sun.com/javase/technologies/compatibility.jsp (sources shouln'd be a problem)
>
> Using release mechanism for such a change is surely a good idea.
>
> Yes it's a little bit faster, on POS it's significant (I think because of the bug I reported below)
>
> Jacques
>
> From: "Andrew Sykes" <[hidden email]>
> > Jacques,
> >
> > My concern would be that once you introduce these features the code is
> > no longer going to compile unless you use 1.5
> >
> > I remember there was a big problem for us between 1.3 and 1.4 because
> > the WorldPay libs we were using were not compatible with 1.4.
> > Fortunately we were able to just continue using 1.3 for a while, but of
> > course that would have been a real problem if there was suddenly
> > incompatible code.
> >
> > I don't know of any issues like this with 1.5, but I'd hate to discover
> > one 5 minutes before home time on a Friday! Hence my cautious attitude.
> >
> > Perhaps we could introduce a single 1.5 code instance somewhere which
> > would enforce an upgrade. This would mean that we could watch for
> > feedback on the ML for a while and offer an easy fix for anyone who was
> > experiencing problems.
> >
> > Alternatively perhaps it would be a good idea to wait until the upcoming
> > release, then if someone has problems, they can simply revert to that
> > release.
> >
> > What do you think?
> >
> > You make an interesting point about speed, I've not run ofbiz with 1.5
> > yet - is it noticeably faster?
> >
> > -Andrew
> >
> > On Tue, 2006-10-03 at 11:40 +0200, Jacques Le Roux wrote:
> > > Hi Andrew,
> > >
> > > My comments inline.
> > >
> > > From: "Andrew Sykes" <[hidden email]>
> > > > Jacques,
> > > >
> > > > What features do you have in mind?
> > >
> > > C# like (notably foreach like loops but also autoboxing, enum type and  varargs)
> > > For more please see : http://java.sun.com/j2se/1.5.0/docs/guide/language/index.html
> > >
> > > > Stuff like autoboxing and foreach loops would probably reduce the
> > > > overall code size, but would also stop people from using an older JDK.
> > >
> > > Yes, one day or another we will have to do it anyway, why waiting ?
> > > It's not difficult to switch from 1.4 to 1.5.
> > > They are some bugs solved (notably this one which was annoying in POS (block debugging in Eclipse, ok in NetBeans) :
> > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6330496)
> > > And last but not least it's faster :o)
> > >
> > > > Removing support for 1.4x might mean people's proprietary modifications
> > > > or libraries cease to be compatible.
> > >
> > > Yes that's might be a *problem*. Are you already aware of such cases (or anybody else of course) ?
> > >
> > > > Are you suggesting this change for existing code or new code?
> > >
> > > I was thinking primarily at new code. When refactoring old code (bug, improvements, etc.) 1.5 new features may be also used.
> > >
> > > Jacques
> > >
> > > >
> > > > On Tue, 2006-10-03 at 07:56 +0200, Jacques Le Roux wrote:
> > > > > Hi Developpers,
> > > > >
> > > > > Now that JDK 1.5 is no longer a problem I propose to vote on using 1.5 new features. What do you think ?
> > > > >
> > > > > Jacques
> > >
> > --
> > Kind Regards
> > Andrew Sykes <[hidden email]>
> > Sykes Development Ltd
> > http://www.sykesdevelopment.com
--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

Reply | Threaded
Open this post in threaded view
|

Re: JDK 1.5 new features

cjhowe
In reply to this post by Jacques Le Roux
I would opt for a wait and see from the Sun camp.
With 1.6 in Beta 2 and open source, it would be better
to write to 1.6 spec on new stuff.  As I understand it
(which is ONLY from reading about it) 1.5 doesn't
offer any real benefit, but 1.6 is supposed to offer
better speed. And with the open source aspect, may
make for the opportunity for a specialized ofbiz java
environment.

--- Jacques Le Roux <[hidden email]>
wrote:

> Andrew,
>
> I understand your position (indeed we have enough
> problems to solve). Let's see what others think...
>
> Perhaps a solution :
> http://retroweaver.sourceforge.net/
> Though if you have not the souce code and only jars
> this is not a solution :(
>
> What Sun says :
>
http://java.sun.com/javase/technologies/compatibility.jsp

> (sources shouln'd be a problem)
>
> Using release mechanism for such a change is surely
> a good idea.
>
> Yes it's a little bit faster, on POS it's
> significant (I think because of the bug I reported
> below)
>
> Jacques
>
> From: "Andrew Sykes" <[hidden email]>
> > Jacques,
> >
> > My concern would be that once you introduce these
> features the code is
> > no longer going to compile unless you use 1.5
> >
> > I remember there was a big problem for us between
> 1.3 and 1.4 because
> > the WorldPay libs we were using were not
> compatible with 1.4.
> > Fortunately we were able to just continue using
> 1.3 for a while, but of
> > course that would have been a real problem if
> there was suddenly
> > incompatible code.
> >
> > I don't know of any issues like this with 1.5, but
> I'd hate to discover
> > one 5 minutes before home time on a Friday! Hence
> my cautious attitude.
> >
> > Perhaps we could introduce a single 1.5 code
> instance somewhere which
> > would enforce an upgrade. This would mean that we
> could watch for
> > feedback on the ML for a while and offer an easy
> fix for anyone who was
> > experiencing problems.
> >
> > Alternatively perhaps it would be a good idea to
> wait until the upcoming
> > release, then if someone has problems, they can
> simply revert to that
> > release.
> >
> > What do you think?
> >
> > You make an interesting point about speed, I've
> not run ofbiz with 1.5
> > yet - is it noticeably faster?
> >
> > -Andrew
> >
> > On Tue, 2006-10-03 at 11:40 +0200, Jacques Le Roux
> wrote:
> > > Hi Andrew,
> > >
> > > My comments inline.
> > >
> > > From: "Andrew Sykes"
> <[hidden email]>
> > > > Jacques,
> > > >
> > > > What features do you have in mind?
> > >
> > > C# like (notably foreach like loops but also
> autoboxing, enum type and  varargs)
> > > For more please see :
>
http://java.sun.com/j2se/1.5.0/docs/guide/language/index.html

> > >
> > > > Stuff like autoboxing and foreach loops would
> probably reduce the
> > > > overall code size, but would also stop people
> from using an older JDK.
> > >
> > > Yes, one day or another we will have to do it
> anyway, why waiting ?
> > > It's not difficult to switch from 1.4 to 1.5.
> > > They are some bugs solved (notably this one
> which was annoying in POS (block debugging in
> Eclipse, ok in NetBeans) :
> > >
>
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6330496)

> > > And last but not least it's faster :o)
> > >
> > > > Removing support for 1.4x might mean people's
> proprietary modifications
> > > > or libraries cease to be compatible.
> > >
> > > Yes that's might be a *problem*. Are you already
> aware of such cases (or anybody else of course) ?
> > >
> > > > Are you suggesting this change for existing
> code or new code?
> > >
> > > I was thinking primarily at new code. When
> refactoring old code (bug, improvements, etc.) 1.5
> new features may be also used.
> > >
> > > Jacques
> > >
> > > >
> > > > On Tue, 2006-10-03 at 07:56 +0200, Jacques Le
> Roux wrote:
> > > > > Hi Developpers,
> > > > >
> > > > > Now that JDK 1.5 is no longer a problem I
> propose to vote on using 1.5 new features. What do
> you think ?
> > > > >
> > > > > Jacques
> > >
> > --
> > Kind Regards
> > Andrew Sykes <[hidden email]>
> > Sykes Development Ltd
> > http://www.sykesdevelopment.com
>

Reply | Threaded
Open this post in threaded view
|

Re: JDK 1.5 new features

David E Jones-2

In general with this in the past we have waited until a specific  
version of Java has matured and is widely available across many  
platforms in a stable state, and that it is commonly used.

With OFBiz our goal is not to be on the bleeding edge of what is  
happening in the Java world, unless of course whatever is new has  
enough of an impact on what we are doing that the downsides of early  
adoption are well worth it. So far that hasn't happened with the JDK  
stuff...

Java 1.5 has been around long enough and is widely enough supported  
that we could probably more seriously consider moving to that now.  
Jumping to 1.6 would probably be a bad idea as many platforms would  
have a hard time with it initially (and multi-platform is a very  
important part of why we use Java, one of many of course). Chances  
are 1.6 will be out for at least a year before we require it.

-David


On Oct 3, 2006, at 3:07 PM, Chris Howe wrote:

> I would opt for a wait and see from the Sun camp.
> With 1.6 in Beta 2 and open source, it would be better
> to write to 1.6 spec on new stuff.  As I understand it
> (which is ONLY from reading about it) 1.5 doesn't
> offer any real benefit, but 1.6 is supposed to offer
> better speed. And with the open source aspect, may
> make for the opportunity for a specialized ofbiz java
> environment.
>
> --- Jacques Le Roux <[hidden email]>
> wrote:
>
>> Andrew,
>>
>> I understand your position (indeed we have enough
>> problems to solve). Let's see what others think...
>>
>> Perhaps a solution :
>> http://retroweaver.sourceforge.net/
>> Though if you have not the souce code and only jars
>> this is not a solution :(
>>
>> What Sun says :
>>
> http://java.sun.com/javase/technologies/compatibility.jsp
>> (sources shouln'd be a problem)
>>
>> Using release mechanism for such a change is surely
>> a good idea.
>>
>> Yes it's a little bit faster, on POS it's
>> significant (I think because of the bug I reported
>> below)
>>
>> Jacques
>>
>> From: "Andrew Sykes" <[hidden email]>
>>> Jacques,
>>>
>>> My concern would be that once you introduce these
>> features the code is
>>> no longer going to compile unless you use 1.5
>>>
>>> I remember there was a big problem for us between
>> 1.3 and 1.4 because
>>> the WorldPay libs we were using were not
>> compatible with 1.4.
>>> Fortunately we were able to just continue using
>> 1.3 for a while, but of
>>> course that would have been a real problem if
>> there was suddenly
>>> incompatible code.
>>>
>>> I don't know of any issues like this with 1.5, but
>> I'd hate to discover
>>> one 5 minutes before home time on a Friday! Hence
>> my cautious attitude.
>>>
>>> Perhaps we could introduce a single 1.5 code
>> instance somewhere which
>>> would enforce an upgrade. This would mean that we
>> could watch for
>>> feedback on the ML for a while and offer an easy
>> fix for anyone who was
>>> experiencing problems.
>>>
>>> Alternatively perhaps it would be a good idea to
>> wait until the upcoming
>>> release, then if someone has problems, they can
>> simply revert to that
>>> release.
>>>
>>> What do you think?
>>>
>>> You make an interesting point about speed, I've
>> not run ofbiz with 1.5
>>> yet - is it noticeably faster?
>>>
>>> -Andrew
>>>
>>> On Tue, 2006-10-03 at 11:40 +0200, Jacques Le Roux
>> wrote:
>>>> Hi Andrew,
>>>>
>>>> My comments inline.
>>>>
>>>> From: "Andrew Sykes"
>> <[hidden email]>
>>>>> Jacques,
>>>>>
>>>>> What features do you have in mind?
>>>>
>>>> C# like (notably foreach like loops but also
>> autoboxing, enum type and  varargs)
>>>> For more please see :
>>
> http://java.sun.com/j2se/1.5.0/docs/guide/language/index.html
>>>>
>>>>> Stuff like autoboxing and foreach loops would
>> probably reduce the
>>>>> overall code size, but would also stop people
>> from using an older JDK.
>>>>
>>>> Yes, one day or another we will have to do it
>> anyway, why waiting ?
>>>> It's not difficult to switch from 1.4 to 1.5.
>>>> They are some bugs solved (notably this one
>> which was annoying in POS (block debugging in
>> Eclipse, ok in NetBeans) :
>>>>
>>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6330496)
>>>> And last but not least it's faster :o)
>>>>
>>>>> Removing support for 1.4x might mean people's
>> proprietary modifications
>>>>> or libraries cease to be compatible.
>>>>
>>>> Yes that's might be a *problem*. Are you already
>> aware of such cases (or anybody else of course) ?
>>>>
>>>>> Are you suggesting this change for existing
>> code or new code?
>>>>
>>>> I was thinking primarily at new code. When
>> refactoring old code (bug, improvements, etc.) 1.5
>> new features may be also used.
>>>>
>>>> Jacques
>>>>
>>>>>
>>>>> On Tue, 2006-10-03 at 07:56 +0200, Jacques Le
>> Roux wrote:
>>>>>> Hi Developpers,
>>>>>>
>>>>>> Now that JDK 1.5 is no longer a problem I
>> propose to vote on using 1.5 new features. What do
>> you think ?
>>>>>>
>>>>>> Jacques
>>>>
>>> --
>>> Kind Regards
>>> Andrew Sykes <[hidden email]>
>>> Sykes Development Ltd
>>> http://www.sykesdevelopment.com
>>
>