commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <GGreg...@seagullsoftware.com>
Subject RE: [lang] Java 5
Date Fri, 20 Jun 2008 18:58:37 GMT
Good plain from Niall IMO.
Gary

-----Original Message-----
From: Niall Pemberton [mailto:niall.pemberton@gmail.com]
Sent: Friday, June 20, 2008 11:21 AM
To: Commons Developers List
Subject: Re: [lang] Java 5

On Fri, Jun 20, 2008 at 4:42 PM, Henri Yandell <flamefew@gmail.com> wrote:
> On Thu, Jun 12, 2008 at 5:05 AM, sebb <sebbaz@gmail.com> wrote:
>> On 12/06/2008, James Carman <james@carmanconsulting.com> wrote:
>>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>>>
>>> <niall.pemberton@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.

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


Mime
View raw message