You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Matt Benson <gu...@yahoo.com> on 2008/10/10 16:44:10 UTC
Re: [lang] Java 5
Resurrecting this thread from 3.5 months ago as my
itch is returning:
--- Niall Pemberton <ni...@gmail.com> wrote:
> On Fri, Jun 20, 2008 at 4:42 PM, Henri Yandell
> <fl...@gmail.com> wrote:
> > On Thu, Jun 12, 2008 at 5:05 AM, sebb
> <se...@gmail.com> wrote:
> >> On 12/06/2008, James Carman
> <ja...@carmanconsulting.com> wrote:
> >>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
> >>>
> >>> <ni...@gmail.com> wrote:
> >>>
> >>>
> >>> >> Do you mean that the removal of the enums
> would mean that we have to
> >>> >> change package names?
> >>> >>
> >>> >> Would class/interface removals necessitate a
> >>> >> package name change? I haven't really
> thought that through.
> >>> >
> >>> > Perhaps not, neither had I
> >>> >
> >>
> >> Removal of a *public* interface/method/class
> means that the API is not
> >> compatible, as it is not possible to replace the
> jar without breaking
> >> classes that use these items.
> >
> > I think we need to make a final decision on this.
> >
> > There seems little argument against moving to 1.5
> in theory. And no
> > one is concerned with using 1.5 features in new
> development. The one
> > open question is: "Should we rename the package"?
> >
> > * If we goto 1.5, we have to remove the enum
> package. It's been
> > deprecated for a good while and a source code fix
> is very easy. Any
> > client that is 1.5 based has had to remove it
> already.
> >
> > * We have a handful of other deprecated methods
> that we've said will
> > be removed in 3.0. We've removed methods in the
> past (I'm pretty sure
> > we did that for 2.0).
> >
> > I'm 50/50 right now. On the one hand, yes I think
> we should remove
> > things and it's not a major version problem. If
> people are having pain
> > it would be very easy to build a separate jar with
> the deprecated
> > methods. However.... if we are going to start
> writing new generics
> > code etc, it is going to be impossible to manage
> to keep that separate
> > from the existing code. How will people know what
> to code where?
> >
> > In which case I think we should just dive right
> into LangTwo now. svn
> > cp the trunk to a branch for maintenance, and
> release of the current
> > bugfixes if we ever need to, and start a new
> LangTwo on the current
> > trunk.
>
> *If* lang2 breaks compatibility, then IMO we should
> use a new package
> name, but moving to JDK 1.5 minimum doesn't
> necessarily dictate that
> (assuming that we release a compatibility jar for
> the enum package
> which has to be removed). IMO it would be better to
> go through putting
> in the JDK 1.5 features that don't break
> compatibility and building up
> a list of possible changes that do. Then we make the
> decision on
> whether compatibility-breaking features seem worth
> it. If it is, then
> lets go all the way, remove deprecations, change the
> package name and
> put them in. If not, then lets leave the package
> name and
> deprecations. We've had a similar discussion over
> Commons IO and IMO
> so far nothing has come up that seems worth the
> whole sale package
> name change - so I think making the decision first,
> without any JDK
> 1.5+ features on the table for consideration is a
> mistake.
Let's see, adding generics shouldn't break
compatibility; would varargs? Beyond that anything
_added_ doesn't break compatibility because we're
talking about existing code with drop-in jar
replacement, right? Have I correctly outlined the
differences between breaking and non-breaking changes
in this context? If so, I'd like to go ahead and
start with the plan. More likely I've missed
something; let's flush it out.
-Matt
>
> Niall
>
> > Gump btw is going to go mad :) It'll think we're
> breaking compatibility.
> >
> > Hen
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@commons.apache.org
> For additional commands, e-mail:
> dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Re: [lang] Java 5
Posted by Hendrik Maryns <he...@uni-tuebingen.de>.
Viraj Turakhia schreef:
> +1 in moving to JDK 1.5.
>
> New contributor, but always wanted to see 1.5 supported libraries in commons.
+1, same remark. I generified both Collections and Lang some years ago,
this might be of help, but I never got them compiling in javac, Eclipse
compiles it fine. There is only one warning concerning generics left.
See http://tcl.sfs.uni-tuebingen.de/~hendrik/ (under the first heading).
And currently working on generifying CLI trunk.
H.
--
Hendrik Maryns
Herrenberger Straße 40
D-72070 Tübingen
+49707143783
http://tcl.sfs.uni-tuebingen.de/~hendrik/
=================
www.lieverleven.be Hier kan iedereen wat van leren.
Re: [lang] Java 5
Posted by Viraj Turakhia <vi...@gmail.com>.
+1 in moving to JDK 1.5.
New contributor, but always wanted to see 1.5 supported libraries in commons.
-v
On Fri, Oct 10, 2008 at 9:53 PM, Simone Gianni <si...@apache.org> wrote:
> Yes, I do agree, but again I'm completely non binding. Migrating code to
> new packages (or new classnames) where binary compatibility cannot be
> granted. Unfortunately I cannot foresee how many places would need to be
> refactored to support "double" classes/packages ... internally I mean,
> from a user POV they will call the new class in the the new package if
> they want/need support for jdk5 stuff.
>
> Simone
>
> James Carman wrote:
>> I'm +1 for moving forward, but I would rather change the package name
>> rather than break backward compatibility. There are a lot of
>> libraries out there that depend on commons-* and you may need older
>> versions on your classpath to get them to work.
>>
>> On Fri, Oct 10, 2008 at 11:07 AM, Simone Gianni <si...@apache.org> wrote:
>>
>>> Hi all,
>>> non binding +1 for moving to new versions supporting JDK 5 features,
>>> even if breaking compatibility with older versions and rewriting APIs.
>>> There is a lack of good libraries like lang, beanutils etc.. in the
>>> post-1.5 jdks (see the recent thread i participated in regarding
>>> generics), and many projects are dealing with problems with generics,
>>> enums and so on.
>>>
>>> Simone
>>>
>>> James Carman wrote:
>>>
>>>> Matt, good idea to revive this. Commons needs to come to grips with
>>>> JDK5. It reaches its EOSL on 10/30/2009 and our libraries don't even
>>>> support it yet! We need to come up with an approach to this package
>>>> renaming issue and just move forward.
>>>>
>>>> On Fri, Oct 10, 2008 at 10:44 AM, Matt Benson <gu...@yahoo.com> wrote:
>>>>
>>>>
>>>>> Resurrecting this thread from 3.5 months ago as my
>>>>> itch is returning:
>>>>>
>>>>> --- Niall Pemberton <ni...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On Fri, Jun 20, 2008 at 4:42 PM, Henri Yandell
>>>>>> <fl...@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>> On Thu, Jun 12, 2008 at 5:05 AM, sebb
>>>>>>>
>>>>>>>
>>>>>> <se...@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>>> On 12/06/2008, James Carman
>>>>>>>>
>>>>>>>>
>>>>>> <ja...@carmanconsulting.com> wrote:
>>>>>>
>>>>>>
>>>>>>>>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>>>>>>>>>
>>>>>>>>> <ni...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Do you mean that the removal of the enums
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> would mean that we have to
>>>>>>
>>>>>>
>>>>>>>>> >> change package names?
>>>>>>>>> >>
>>>>>>>>> >> Would class/interface removals necessitate a
>>>>>>>>> >> package name change? I haven't really
>>>>>>>>>
>>>>>>>>>
>>>>>> thought that through.
>>>>>>
>>>>>>
>>>>>>>>> >
>>>>>>>>> > Perhaps not, neither had I
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Removal of a *public* interface/method/class
>>>>>>>>
>>>>>>>>
>>>>>> means that the API is not
>>>>>>
>>>>>>
>>>>>>>> compatible, as it is not possible to replace the
>>>>>>>>
>>>>>>>>
>>>>>> jar without breaking
>>>>>>
>>>>>>
>>>>>>>> classes that use these items.
>>>>>>>>
>>>>>>>>
>>>>>>> I think we need to make a final decision on this.
>>>>>>>
>>>>>>> There seems little argument against moving to 1.5
>>>>>>>
>>>>>>>
>>>>>> in theory. And no
>>>>>>
>>>>>>
>>>>>>> one is concerned with using 1.5 features in new
>>>>>>>
>>>>>>>
>>>>>> development. The one
>>>>>>
>>>>>>
>>>>>>> open question is: "Should we rename the package"?
>>>>>>>
>>>>>>> * If we goto 1.5, we have to remove the enum
>>>>>>>
>>>>>>>
>>>>>> package. It's been
>>>>>>
>>>>>>
>>>>>>> deprecated for a good while and a source code fix
>>>>>>>
>>>>>>>
>>>>>> is very easy. Any
>>>>>>
>>>>>>
>>>>>>> client that is 1.5 based has had to remove it
>>>>>>>
>>>>>>>
>>>>>> already.
>>>>>>
>>>>>>
>>>>>>> * We have a handful of other deprecated methods
>>>>>>>
>>>>>>>
>>>>>> that we've said will
>>>>>>
>>>>>>
>>>>>>> be removed in 3.0. We've removed methods in the
>>>>>>>
>>>>>>>
>>>>>> past (I'm pretty sure
>>>>>>
>>>>>>
>>>>>>> we did that for 2.0).
>>>>>>>
>>>>>>> I'm 50/50 right now. On the one hand, yes I think
>>>>>>>
>>>>>>>
>>>>>> we should remove
>>>>>>
>>>>>>
>>>>>>> things and it's not a major version problem. If
>>>>>>>
>>>>>>>
>>>>>> people are having pain
>>>>>>
>>>>>>
>>>>>>> it would be very easy to build a separate jar with
>>>>>>>
>>>>>>>
>>>>>> the deprecated
>>>>>>
>>>>>>
>>>>>>> methods. However.... if we are going to start
>>>>>>>
>>>>>>>
>>>>>> writing new generics
>>>>>>
>>>>>>
>>>>>>> code etc, it is going to be impossible to manage
>>>>>>>
>>>>>>>
>>>>>> to keep that separate
>>>>>>
>>>>>>
>>>>>>> from the existing code. How will people know what
>>>>>>>
>>>>>>>
>>>>>> to code where?
>>>>>>
>>>>>>
>>>>>>> In which case I think we should just dive right
>>>>>>>
>>>>>>>
>>>>>> into LangTwo now. svn
>>>>>>
>>>>>>
>>>>>>> cp the trunk to a branch for maintenance, and
>>>>>>>
>>>>>>>
>>>>>> release of the current
>>>>>>
>>>>>>
>>>>>>> bugfixes if we ever need to, and start a new
>>>>>>>
>>>>>>>
>>>>>> LangTwo on the current
>>>>>>
>>>>>>
>>>>>>> trunk.
>>>>>>>
>>>>>>>
>>>>>> *If* lang2 breaks compatibility, then IMO we should
>>>>>> use a new package
>>>>>> name, but moving to JDK 1.5 minimum doesn't
>>>>>> necessarily dictate that
>>>>>> (assuming that we release a compatibility jar for
>>>>>> the enum package
>>>>>> which has to be removed). IMO it would be better to
>>>>>> go through putting
>>>>>> in the JDK 1.5 features that don't break
>>>>>> compatibility and building up
>>>>>> a list of possible changes that do. Then we make the
>>>>>> decision on
>>>>>> whether compatibility-breaking features seem worth
>>>>>> it. If it is, then
>>>>>> lets go all the way, remove deprecations, change the
>>>>>> package name and
>>>>>> put them in. If not, then lets leave the package
>>>>>> name and
>>>>>> deprecations. We've had a similar discussion over
>>>>>> Commons IO and IMO
>>>>>> so far nothing has come up that seems worth the
>>>>>> whole sale package
>>>>>> name change - so I think making the decision first,
>>>>>> without any JDK
>>>>>> 1.5+ features on the table for consideration is a
>>>>>> mistake.
>>>>>>
>>>>>>
>>>>> Let's see, adding generics shouldn't break
>>>>> compatibility; would varargs? Beyond that anything
>>>>> _added_ doesn't break compatibility because we're
>>>>> talking about existing code with drop-in jar
>>>>> replacement, right? Have I correctly outlined the
>>>>> differences between breaking and non-breaking changes
>>>>> in this context? If so, I'd like to go ahead and
>>>>> start with the plan. More likely I've missed
>>>>> something; let's flush it out.
>>>>>
>>>>> -Matt
>>>>>
>>>>>
>>>>>
>>>>>> Niall
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Gump btw is going to go mad :) It'll think we're
>>>>>>>
>>>>>>>
>>>>>> breaking compatibility.
>>>>>>
>>>>>>
>>>>>>> Hen
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>
>>>>>
>>>>>> To unsubscribe, e-mail:
>>>>>> dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail:
>>>>>> dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>>
>>> --
>>> Simone Gianni CEO Semeru s.r.l. Apache Committer
>>> MALE human being programming a computer http://www.simonegianni.it/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> Simone Gianni CEO Semeru s.r.l. Apache Committer
> MALE human being programming a computer http://www.simonegianni.it/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
The first right of human is the right of EGO.
--
http://www.xperienceexperience.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by Simone Gianni <si...@apache.org>.
Yes, I do agree, but again I'm completely non binding. Migrating code to
new packages (or new classnames) where binary compatibility cannot be
granted. Unfortunately I cannot foresee how many places would need to be
refactored to support "double" classes/packages ... internally I mean,
from a user POV they will call the new class in the the new package if
they want/need support for jdk5 stuff.
Simone
James Carman wrote:
> I'm +1 for moving forward, but I would rather change the package name
> rather than break backward compatibility. There are a lot of
> libraries out there that depend on commons-* and you may need older
> versions on your classpath to get them to work.
>
> On Fri, Oct 10, 2008 at 11:07 AM, Simone Gianni <si...@apache.org> wrote:
>
>> Hi all,
>> non binding +1 for moving to new versions supporting JDK 5 features,
>> even if breaking compatibility with older versions and rewriting APIs.
>> There is a lack of good libraries like lang, beanutils etc.. in the
>> post-1.5 jdks (see the recent thread i participated in regarding
>> generics), and many projects are dealing with problems with generics,
>> enums and so on.
>>
>> Simone
>>
>> James Carman wrote:
>>
>>> Matt, good idea to revive this. Commons needs to come to grips with
>>> JDK5. It reaches its EOSL on 10/30/2009 and our libraries don't even
>>> support it yet! We need to come up with an approach to this package
>>> renaming issue and just move forward.
>>>
>>> On Fri, Oct 10, 2008 at 10:44 AM, Matt Benson <gu...@yahoo.com> wrote:
>>>
>>>
>>>> Resurrecting this thread from 3.5 months ago as my
>>>> itch is returning:
>>>>
>>>> --- Niall Pemberton <ni...@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>>> On Fri, Jun 20, 2008 at 4:42 PM, Henri Yandell
>>>>> <fl...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>> On Thu, Jun 12, 2008 at 5:05 AM, sebb
>>>>>>
>>>>>>
>>>>> <se...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>>> On 12/06/2008, James Carman
>>>>>>>
>>>>>>>
>>>>> <ja...@carmanconsulting.com> wrote:
>>>>>
>>>>>
>>>>>>>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>>>>>>>>
>>>>>>>> <ni...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>> Do you mean that the removal of the enums
>>>>>>>>>>
>>>>>>>>>>
>>>>> would mean that we have to
>>>>>
>>>>>
>>>>>>>> >> change package names?
>>>>>>>> >>
>>>>>>>> >> Would class/interface removals necessitate a
>>>>>>>> >> package name change? I haven't really
>>>>>>>>
>>>>>>>>
>>>>> thought that through.
>>>>>
>>>>>
>>>>>>>> >
>>>>>>>> > Perhaps not, neither had I
>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>> Removal of a *public* interface/method/class
>>>>>>>
>>>>>>>
>>>>> means that the API is not
>>>>>
>>>>>
>>>>>>> compatible, as it is not possible to replace the
>>>>>>>
>>>>>>>
>>>>> jar without breaking
>>>>>
>>>>>
>>>>>>> classes that use these items.
>>>>>>>
>>>>>>>
>>>>>> I think we need to make a final decision on this.
>>>>>>
>>>>>> There seems little argument against moving to 1.5
>>>>>>
>>>>>>
>>>>> in theory. And no
>>>>>
>>>>>
>>>>>> one is concerned with using 1.5 features in new
>>>>>>
>>>>>>
>>>>> development. The one
>>>>>
>>>>>
>>>>>> open question is: "Should we rename the package"?
>>>>>>
>>>>>> * If we goto 1.5, we have to remove the enum
>>>>>>
>>>>>>
>>>>> package. It's been
>>>>>
>>>>>
>>>>>> deprecated for a good while and a source code fix
>>>>>>
>>>>>>
>>>>> is very easy. Any
>>>>>
>>>>>
>>>>>> client that is 1.5 based has had to remove it
>>>>>>
>>>>>>
>>>>> already.
>>>>>
>>>>>
>>>>>> * We have a handful of other deprecated methods
>>>>>>
>>>>>>
>>>>> that we've said will
>>>>>
>>>>>
>>>>>> be removed in 3.0. We've removed methods in the
>>>>>>
>>>>>>
>>>>> past (I'm pretty sure
>>>>>
>>>>>
>>>>>> we did that for 2.0).
>>>>>>
>>>>>> I'm 50/50 right now. On the one hand, yes I think
>>>>>>
>>>>>>
>>>>> we should remove
>>>>>
>>>>>
>>>>>> things and it's not a major version problem. If
>>>>>>
>>>>>>
>>>>> people are having pain
>>>>>
>>>>>
>>>>>> it would be very easy to build a separate jar with
>>>>>>
>>>>>>
>>>>> the deprecated
>>>>>
>>>>>
>>>>>> methods. However.... if we are going to start
>>>>>>
>>>>>>
>>>>> writing new generics
>>>>>
>>>>>
>>>>>> code etc, it is going to be impossible to manage
>>>>>>
>>>>>>
>>>>> to keep that separate
>>>>>
>>>>>
>>>>>> from the existing code. How will people know what
>>>>>>
>>>>>>
>>>>> to code where?
>>>>>
>>>>>
>>>>>> In which case I think we should just dive right
>>>>>>
>>>>>>
>>>>> into LangTwo now. svn
>>>>>
>>>>>
>>>>>> cp the trunk to a branch for maintenance, and
>>>>>>
>>>>>>
>>>>> release of the current
>>>>>
>>>>>
>>>>>> bugfixes if we ever need to, and start a new
>>>>>>
>>>>>>
>>>>> LangTwo on the current
>>>>>
>>>>>
>>>>>> trunk.
>>>>>>
>>>>>>
>>>>> *If* lang2 breaks compatibility, then IMO we should
>>>>> use a new package
>>>>> name, but moving to JDK 1.5 minimum doesn't
>>>>> necessarily dictate that
>>>>> (assuming that we release a compatibility jar for
>>>>> the enum package
>>>>> which has to be removed). IMO it would be better to
>>>>> go through putting
>>>>> in the JDK 1.5 features that don't break
>>>>> compatibility and building up
>>>>> a list of possible changes that do. Then we make the
>>>>> decision on
>>>>> whether compatibility-breaking features seem worth
>>>>> it. If it is, then
>>>>> lets go all the way, remove deprecations, change the
>>>>> package name and
>>>>> put them in. If not, then lets leave the package
>>>>> name and
>>>>> deprecations. We've had a similar discussion over
>>>>> Commons IO and IMO
>>>>> so far nothing has come up that seems worth the
>>>>> whole sale package
>>>>> name change - so I think making the decision first,
>>>>> without any JDK
>>>>> 1.5+ features on the table for consideration is a
>>>>> mistake.
>>>>>
>>>>>
>>>> Let's see, adding generics shouldn't break
>>>> compatibility; would varargs? Beyond that anything
>>>> _added_ doesn't break compatibility because we're
>>>> talking about existing code with drop-in jar
>>>> replacement, right? Have I correctly outlined the
>>>> differences between breaking and non-breaking changes
>>>> in this context? If so, I'd like to go ahead and
>>>> start with the plan. More likely I've missed
>>>> something; let's flush it out.
>>>>
>>>> -Matt
>>>>
>>>>
>>>>
>>>>> Niall
>>>>>
>>>>>
>>>>>
>>>>>> Gump btw is going to go mad :) It'll think we're
>>>>>>
>>>>>>
>>>>> breaking compatibility.
>>>>>
>>>>>
>>>>>> Hen
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>>
>>>>
>>>>> To unsubscribe, e-mail:
>>>>> dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail:
>>>>> dev-help@commons.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>>
>> --
>> Simone Gianni CEO Semeru s.r.l. Apache Committer
>> MALE human being programming a computer http://www.simonegianni.it/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Simone Gianni CEO Semeru s.r.l. Apache Committer
MALE human being programming a computer http://www.simonegianni.it/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by James Carman <ja...@carmanconsulting.com>.
I'm +1 for moving forward, but I would rather change the package name
rather than break backward compatibility. There are a lot of
libraries out there that depend on commons-* and you may need older
versions on your classpath to get them to work.
On Fri, Oct 10, 2008 at 11:07 AM, Simone Gianni <si...@apache.org> wrote:
> Hi all,
> non binding +1 for moving to new versions supporting JDK 5 features,
> even if breaking compatibility with older versions and rewriting APIs.
> There is a lack of good libraries like lang, beanutils etc.. in the
> post-1.5 jdks (see the recent thread i participated in regarding
> generics), and many projects are dealing with problems with generics,
> enums and so on.
>
> Simone
>
> James Carman wrote:
>> Matt, good idea to revive this. Commons needs to come to grips with
>> JDK5. It reaches its EOSL on 10/30/2009 and our libraries don't even
>> support it yet! We need to come up with an approach to this package
>> renaming issue and just move forward.
>>
>> On Fri, Oct 10, 2008 at 10:44 AM, Matt Benson <gu...@yahoo.com> wrote:
>>
>>> Resurrecting this thread from 3.5 months ago as my
>>> itch is returning:
>>>
>>> --- Niall Pemberton <ni...@gmail.com> wrote:
>>>
>>>
>>>> On Fri, Jun 20, 2008 at 4:42 PM, Henri Yandell
>>>> <fl...@gmail.com> wrote:
>>>>
>>>>> On Thu, Jun 12, 2008 at 5:05 AM, sebb
>>>>>
>>>> <se...@gmail.com> wrote:
>>>>
>>>>>> On 12/06/2008, James Carman
>>>>>>
>>>> <ja...@carmanconsulting.com> wrote:
>>>>
>>>>>>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>>>>>>>
>>>>>>> <ni...@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> Do you mean that the removal of the enums
>>>>>>>>>
>>>> would mean that we have to
>>>>
>>>>>>> >> change package names?
>>>>>>> >>
>>>>>>> >> Would class/interface removals necessitate a
>>>>>>> >> package name change? I haven't really
>>>>>>>
>>>> thought that through.
>>>>
>>>>>>> >
>>>>>>> > Perhaps not, neither had I
>>>>>>> >
>>>>>>>
>>>>>> Removal of a *public* interface/method/class
>>>>>>
>>>> means that the API is not
>>>>
>>>>>> compatible, as it is not possible to replace the
>>>>>>
>>>> jar without breaking
>>>>
>>>>>> classes that use these items.
>>>>>>
>>>>> I think we need to make a final decision on this.
>>>>>
>>>>> There seems little argument against moving to 1.5
>>>>>
>>>> in theory. And no
>>>>
>>>>> one is concerned with using 1.5 features in new
>>>>>
>>>> development. The one
>>>>
>>>>> open question is: "Should we rename the package"?
>>>>>
>>>>> * If we goto 1.5, we have to remove the enum
>>>>>
>>>> package. It's been
>>>>
>>>>> deprecated for a good while and a source code fix
>>>>>
>>>> is very easy. Any
>>>>
>>>>> client that is 1.5 based has had to remove it
>>>>>
>>>> already.
>>>>
>>>>> * We have a handful of other deprecated methods
>>>>>
>>>> that we've said will
>>>>
>>>>> be removed in 3.0. We've removed methods in the
>>>>>
>>>> past (I'm pretty sure
>>>>
>>>>> we did that for 2.0).
>>>>>
>>>>> I'm 50/50 right now. On the one hand, yes I think
>>>>>
>>>> we should remove
>>>>
>>>>> things and it's not a major version problem. If
>>>>>
>>>> people are having pain
>>>>
>>>>> it would be very easy to build a separate jar with
>>>>>
>>>> the deprecated
>>>>
>>>>> methods. However.... if we are going to start
>>>>>
>>>> writing new generics
>>>>
>>>>> code etc, it is going to be impossible to manage
>>>>>
>>>> to keep that separate
>>>>
>>>>> from the existing code. How will people know what
>>>>>
>>>> to code where?
>>>>
>>>>> In which case I think we should just dive right
>>>>>
>>>> into LangTwo now. svn
>>>>
>>>>> cp the trunk to a branch for maintenance, and
>>>>>
>>>> release of the current
>>>>
>>>>> bugfixes if we ever need to, and start a new
>>>>>
>>>> LangTwo on the current
>>>>
>>>>> trunk.
>>>>>
>>>> *If* lang2 breaks compatibility, then IMO we should
>>>> use a new package
>>>> name, but moving to JDK 1.5 minimum doesn't
>>>> necessarily dictate that
>>>> (assuming that we release a compatibility jar for
>>>> the enum package
>>>> which has to be removed). IMO it would be better to
>>>> go through putting
>>>> in the JDK 1.5 features that don't break
>>>> compatibility and building up
>>>> a list of possible changes that do. Then we make the
>>>> decision on
>>>> whether compatibility-breaking features seem worth
>>>> it. If it is, then
>>>> lets go all the way, remove deprecations, change the
>>>> package name and
>>>> put them in. If not, then lets leave the package
>>>> name and
>>>> deprecations. We've had a similar discussion over
>>>> Commons IO and IMO
>>>> so far nothing has come up that seems worth the
>>>> whole sale package
>>>> name change - so I think making the decision first,
>>>> without any JDK
>>>> 1.5+ features on the table for consideration is a
>>>> mistake.
>>>>
>>> Let's see, adding generics shouldn't break
>>> compatibility; would varargs? Beyond that anything
>>> _added_ doesn't break compatibility because we're
>>> talking about existing code with drop-in jar
>>> replacement, right? Have I correctly outlined the
>>> differences between breaking and non-breaking changes
>>> in this context? If so, I'd like to go ahead and
>>> start with the plan. More likely I've missed
>>> something; let's flush it out.
>>>
>>> -Matt
>>>
>>>
>>>> Niall
>>>>
>>>>
>>>>> Gump btw is going to go mad :) It'll think we're
>>>>>
>>>> breaking compatibility.
>>>>
>>>>> Hen
>>>>>
>>>>
>>> ---------------------------------------------------------------------
>>>
>>>> To unsubscribe, e-mail:
>>>> dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail:
>>>> dev-help@commons.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> Simone Gianni CEO Semeru s.r.l. Apache Committer
> MALE human being programming a computer http://www.simonegianni.it/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by Callistus Mendonca <ca...@gmail.com>.
+1 to move to jdk15 even if it means from ground up...
Cal
On Fri, Oct 10, 2008 at 11:07 AM, Simone Gianni <si...@apache.org> wrote:
> Hi all,
> non binding +1 for moving to new versions supporting JDK 5 features,
> even if breaking compatibility with older versions and rewriting APIs.
> There is a lack of good libraries like lang, beanutils etc.. in the
> post-1.5 jdks (see the recent thread i participated in regarding
> generics), and many projects are dealing with problems with generics,
> enums and so on.
>
> Simone
>
> James Carman wrote:
> > Matt, good idea to revive this. Commons needs to come to grips with
> > JDK5. It reaches its EOSL on 10/30/2009 and our libraries don't even
> > support it yet! We need to come up with an approach to this package
> > renaming issue and just move forward.
> >
> > On Fri, Oct 10, 2008 at 10:44 AM, Matt Benson <gu...@yahoo.com>
> wrote:
> >
> >> Resurrecting this thread from 3.5 months ago as my
> >> itch is returning:
> >>
> >> --- Niall Pemberton <ni...@gmail.com> wrote:
> >>
> >>
> >>> On Fri, Jun 20, 2008 at 4:42 PM, Henri Yandell
> >>> <fl...@gmail.com> wrote:
> >>>
> >>>> On Thu, Jun 12, 2008 at 5:05 AM, sebb
> >>>>
> >>> <se...@gmail.com> wrote:
> >>>
> >>>>> On 12/06/2008, James Carman
> >>>>>
> >>> <ja...@carmanconsulting.com> wrote:
> >>>
> >>>>>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
> >>>>>>
> >>>>>> <ni...@gmail.com> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>> Do you mean that the removal of the enums
> >>>>>>>>
> >>> would mean that we have to
> >>>
> >>>>>> >> change package names?
> >>>>>> >>
> >>>>>> >> Would class/interface removals necessitate a
> >>>>>> >> package name change? I haven't really
> >>>>>>
> >>> thought that through.
> >>>
> >>>>>> >
> >>>>>> > Perhaps not, neither had I
> >>>>>> >
> >>>>>>
> >>>>> Removal of a *public* interface/method/class
> >>>>>
> >>> means that the API is not
> >>>
> >>>>> compatible, as it is not possible to replace the
> >>>>>
> >>> jar without breaking
> >>>
> >>>>> classes that use these items.
> >>>>>
> >>>> I think we need to make a final decision on this.
> >>>>
> >>>> There seems little argument against moving to 1.5
> >>>>
> >>> in theory. And no
> >>>
> >>>> one is concerned with using 1.5 features in new
> >>>>
> >>> development. The one
> >>>
> >>>> open question is: "Should we rename the package"?
> >>>>
> >>>> * If we goto 1.5, we have to remove the enum
> >>>>
> >>> package. It's been
> >>>
> >>>> deprecated for a good while and a source code fix
> >>>>
> >>> is very easy. Any
> >>>
> >>>> client that is 1.5 based has had to remove it
> >>>>
> >>> already.
> >>>
> >>>> * We have a handful of other deprecated methods
> >>>>
> >>> that we've said will
> >>>
> >>>> be removed in 3.0. We've removed methods in the
> >>>>
> >>> past (I'm pretty sure
> >>>
> >>>> we did that for 2.0).
> >>>>
> >>>> I'm 50/50 right now. On the one hand, yes I think
> >>>>
> >>> we should remove
> >>>
> >>>> things and it's not a major version problem. If
> >>>>
> >>> people are having pain
> >>>
> >>>> it would be very easy to build a separate jar with
> >>>>
> >>> the deprecated
> >>>
> >>>> methods. However.... if we are going to start
> >>>>
> >>> writing new generics
> >>>
> >>>> code etc, it is going to be impossible to manage
> >>>>
> >>> to keep that separate
> >>>
> >>>> from the existing code. How will people know what
> >>>>
> >>> to code where?
> >>>
> >>>> In which case I think we should just dive right
> >>>>
> >>> into LangTwo now. svn
> >>>
> >>>> cp the trunk to a branch for maintenance, and
> >>>>
> >>> release of the current
> >>>
> >>>> bugfixes if we ever need to, and start a new
> >>>>
> >>> LangTwo on the current
> >>>
> >>>> trunk.
> >>>>
> >>> *If* lang2 breaks compatibility, then IMO we should
> >>> use a new package
> >>> name, but moving to JDK 1.5 minimum doesn't
> >>> necessarily dictate that
> >>> (assuming that we release a compatibility jar for
> >>> the enum package
> >>> which has to be removed). IMO it would be better to
> >>> go through putting
> >>> in the JDK 1.5 features that don't break
> >>> compatibility and building up
> >>> a list of possible changes that do. Then we make the
> >>> decision on
> >>> whether compatibility-breaking features seem worth
> >>> it. If it is, then
> >>> lets go all the way, remove deprecations, change the
> >>> package name and
> >>> put them in. If not, then lets leave the package
> >>> name and
> >>> deprecations. We've had a similar discussion over
> >>> Commons IO and IMO
> >>> so far nothing has come up that seems worth the
> >>> whole sale package
> >>> name change - so I think making the decision first,
> >>> without any JDK
> >>> 1.5+ features on the table for consideration is a
> >>> mistake.
> >>>
> >> Let's see, adding generics shouldn't break
> >> compatibility; would varargs? Beyond that anything
> >> _added_ doesn't break compatibility because we're
> >> talking about existing code with drop-in jar
> >> replacement, right? Have I correctly outlined the
> >> differences between breaking and non-breaking changes
> >> in this context? If so, I'd like to go ahead and
> >> start with the plan. More likely I've missed
> >> something; let's flush it out.
> >>
> >> -Matt
> >>
> >>
> >>> Niall
> >>>
> >>>
> >>>> Gump btw is going to go mad :) It'll think we're
> >>>>
> >>> breaking compatibility.
> >>>
> >>>> Hen
> >>>>
> >>>
> >> ---------------------------------------------------------------------
> >>
> >>> To unsubscribe, e-mail:
> >>> dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail:
> >>> dev-help@commons.apache.org
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> Simone Gianni CEO Semeru s.r.l. Apache Committer
> MALE human being programming a computer http://www.simonegianni.it/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Regards,
Callistus Mendonca
Re: [lang] Java 5
Posted by Simone Gianni <si...@apache.org>.
Hi all,
non binding +1 for moving to new versions supporting JDK 5 features,
even if breaking compatibility with older versions and rewriting APIs.
There is a lack of good libraries like lang, beanutils etc.. in the
post-1.5 jdks (see the recent thread i participated in regarding
generics), and many projects are dealing with problems with generics,
enums and so on.
Simone
James Carman wrote:
> Matt, good idea to revive this. Commons needs to come to grips with
> JDK5. It reaches its EOSL on 10/30/2009 and our libraries don't even
> support it yet! We need to come up with an approach to this package
> renaming issue and just move forward.
>
> On Fri, Oct 10, 2008 at 10:44 AM, Matt Benson <gu...@yahoo.com> wrote:
>
>> Resurrecting this thread from 3.5 months ago as my
>> itch is returning:
>>
>> --- Niall Pemberton <ni...@gmail.com> wrote:
>>
>>
>>> On Fri, Jun 20, 2008 at 4:42 PM, Henri Yandell
>>> <fl...@gmail.com> wrote:
>>>
>>>> On Thu, Jun 12, 2008 at 5:05 AM, sebb
>>>>
>>> <se...@gmail.com> wrote:
>>>
>>>>> On 12/06/2008, James Carman
>>>>>
>>> <ja...@carmanconsulting.com> wrote:
>>>
>>>>>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>>>>>>
>>>>>> <ni...@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> Do you mean that the removal of the enums
>>>>>>>>
>>> would mean that we have to
>>>
>>>>>> >> change package names?
>>>>>> >>
>>>>>> >> Would class/interface removals necessitate a
>>>>>> >> package name change? I haven't really
>>>>>>
>>> thought that through.
>>>
>>>>>> >
>>>>>> > Perhaps not, neither had I
>>>>>> >
>>>>>>
>>>>> Removal of a *public* interface/method/class
>>>>>
>>> means that the API is not
>>>
>>>>> compatible, as it is not possible to replace the
>>>>>
>>> jar without breaking
>>>
>>>>> classes that use these items.
>>>>>
>>>> I think we need to make a final decision on this.
>>>>
>>>> There seems little argument against moving to 1.5
>>>>
>>> in theory. And no
>>>
>>>> one is concerned with using 1.5 features in new
>>>>
>>> development. The one
>>>
>>>> open question is: "Should we rename the package"?
>>>>
>>>> * If we goto 1.5, we have to remove the enum
>>>>
>>> package. It's been
>>>
>>>> deprecated for a good while and a source code fix
>>>>
>>> is very easy. Any
>>>
>>>> client that is 1.5 based has had to remove it
>>>>
>>> already.
>>>
>>>> * We have a handful of other deprecated methods
>>>>
>>> that we've said will
>>>
>>>> be removed in 3.0. We've removed methods in the
>>>>
>>> past (I'm pretty sure
>>>
>>>> we did that for 2.0).
>>>>
>>>> I'm 50/50 right now. On the one hand, yes I think
>>>>
>>> we should remove
>>>
>>>> things and it's not a major version problem. If
>>>>
>>> people are having pain
>>>
>>>> it would be very easy to build a separate jar with
>>>>
>>> the deprecated
>>>
>>>> methods. However.... if we are going to start
>>>>
>>> writing new generics
>>>
>>>> code etc, it is going to be impossible to manage
>>>>
>>> to keep that separate
>>>
>>>> from the existing code. How will people know what
>>>>
>>> to code where?
>>>
>>>> In which case I think we should just dive right
>>>>
>>> into LangTwo now. svn
>>>
>>>> cp the trunk to a branch for maintenance, and
>>>>
>>> release of the current
>>>
>>>> bugfixes if we ever need to, and start a new
>>>>
>>> LangTwo on the current
>>>
>>>> trunk.
>>>>
>>> *If* lang2 breaks compatibility, then IMO we should
>>> use a new package
>>> name, but moving to JDK 1.5 minimum doesn't
>>> necessarily dictate that
>>> (assuming that we release a compatibility jar for
>>> the enum package
>>> which has to be removed). IMO it would be better to
>>> go through putting
>>> in the JDK 1.5 features that don't break
>>> compatibility and building up
>>> a list of possible changes that do. Then we make the
>>> decision on
>>> whether compatibility-breaking features seem worth
>>> it. If it is, then
>>> lets go all the way, remove deprecations, change the
>>> package name and
>>> put them in. If not, then lets leave the package
>>> name and
>>> deprecations. We've had a similar discussion over
>>> Commons IO and IMO
>>> so far nothing has come up that seems worth the
>>> whole sale package
>>> name change - so I think making the decision first,
>>> without any JDK
>>> 1.5+ features on the table for consideration is a
>>> mistake.
>>>
>> Let's see, adding generics shouldn't break
>> compatibility; would varargs? Beyond that anything
>> _added_ doesn't break compatibility because we're
>> talking about existing code with drop-in jar
>> replacement, right? Have I correctly outlined the
>> differences between breaking and non-breaking changes
>> in this context? If so, I'd like to go ahead and
>> start with the plan. More likely I've missed
>> something; let's flush it out.
>>
>> -Matt
>>
>>
>>> Niall
>>>
>>>
>>>> Gump btw is going to go mad :) It'll think we're
>>>>
>>> breaking compatibility.
>>>
>>>> Hen
>>>>
>>>
>> ---------------------------------------------------------------------
>>
>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail:
>>> dev-help@commons.apache.org
>>>
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Simone Gianni CEO Semeru s.r.l. Apache Committer
MALE human being programming a computer http://www.simonegianni.it/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by James Carman <ja...@carmanconsulting.com>.
Matt, good idea to revive this. Commons needs to come to grips with
JDK5. It reaches its EOSL on 10/30/2009 and our libraries don't even
support it yet! We need to come up with an approach to this package
renaming issue and just move forward.
On Fri, Oct 10, 2008 at 10:44 AM, Matt Benson <gu...@yahoo.com> wrote:
> Resurrecting this thread from 3.5 months ago as my
> itch is returning:
>
> --- Niall Pemberton <ni...@gmail.com> wrote:
>
>> On Fri, Jun 20, 2008 at 4:42 PM, Henri Yandell
>> <fl...@gmail.com> wrote:
>> > On Thu, Jun 12, 2008 at 5:05 AM, sebb
>> <se...@gmail.com> wrote:
>> >> On 12/06/2008, James Carman
>> <ja...@carmanconsulting.com> wrote:
>> >>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>> >>>
>> >>> <ni...@gmail.com> wrote:
>> >>>
>> >>>
>> >>> >> Do you mean that the removal of the enums
>> would mean that we have to
>> >>> >> change package names?
>> >>> >>
>> >>> >> Would class/interface removals necessitate a
>> >>> >> package name change? I haven't really
>> thought that through.
>> >>> >
>> >>> > Perhaps not, neither had I
>> >>> >
>> >>
>> >> Removal of a *public* interface/method/class
>> means that the API is not
>> >> compatible, as it is not possible to replace the
>> jar without breaking
>> >> classes that use these items.
>> >
>> > I think we need to make a final decision on this.
>> >
>> > There seems little argument against moving to 1.5
>> in theory. And no
>> > one is concerned with using 1.5 features in new
>> development. The one
>> > open question is: "Should we rename the package"?
>> >
>> > * If we goto 1.5, we have to remove the enum
>> package. It's been
>> > deprecated for a good while and a source code fix
>> is very easy. Any
>> > client that is 1.5 based has had to remove it
>> already.
>> >
>> > * We have a handful of other deprecated methods
>> that we've said will
>> > be removed in 3.0. We've removed methods in the
>> past (I'm pretty sure
>> > we did that for 2.0).
>> >
>> > I'm 50/50 right now. On the one hand, yes I think
>> we should remove
>> > things and it's not a major version problem. If
>> people are having pain
>> > it would be very easy to build a separate jar with
>> the deprecated
>> > methods. However.... if we are going to start
>> writing new generics
>> > code etc, it is going to be impossible to manage
>> to keep that separate
>> > from the existing code. How will people know what
>> to code where?
>> >
>> > In which case I think we should just dive right
>> into LangTwo now. svn
>> > cp the trunk to a branch for maintenance, and
>> release of the current
>> > bugfixes if we ever need to, and start a new
>> LangTwo on the current
>> > trunk.
>>
>> *If* lang2 breaks compatibility, then IMO we should
>> use a new package
>> name, but moving to JDK 1.5 minimum doesn't
>> necessarily dictate that
>> (assuming that we release a compatibility jar for
>> the enum package
>> which has to be removed). IMO it would be better to
>> go through putting
>> in the JDK 1.5 features that don't break
>> compatibility and building up
>> a list of possible changes that do. Then we make the
>> decision on
>> whether compatibility-breaking features seem worth
>> it. If it is, then
>> lets go all the way, remove deprecations, change the
>> package name and
>> put them in. If not, then lets leave the package
>> name and
>> deprecations. We've had a similar discussion over
>> Commons IO and IMO
>> so far nothing has come up that seems worth the
>> whole sale package
>> name change - so I think making the decision first,
>> without any JDK
>> 1.5+ features on the table for consideration is a
>> mistake.
>
> Let's see, adding generics shouldn't break
> compatibility; would varargs? Beyond that anything
> _added_ doesn't break compatibility because we're
> talking about existing code with drop-in jar
> replacement, right? Have I correctly outlined the
> differences between breaking and non-breaking changes
> in this context? If so, I'd like to go ahead and
> start with the plan. More likely I've missed
> something; let's flush it out.
>
> -Matt
>
>>
>> Niall
>>
>> > Gump btw is going to go mad :) It'll think we're
>> breaking compatibility.
>> >
>> > Hen
>>
>>
> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail:
>> dev-help@commons.apache.org
>>
>>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org