commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: [lang] Java 5
Date Fri, 10 Oct 2008 14:44:10 GMT
Resurrecting this thread from 3.5 months ago as my
itch is returning:

--- Niall Pemberton <niall.pemberton@gmail.com> wrote:

> 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.

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


Mime
View raw message