commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Callistus Mendonca" <callistus.mendo...@gmail.com>
Subject Re: [lang] Java 5
Date Fri, 10 Oct 2008 15:59:12 GMT
+1 to move to jdk15 even if it means from ground up...

Cal

On Fri, Oct 10, 2008 at 11:07 AM, Simone Gianni <simoneg@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 <gudnabrsam@yahoo.com>
> wrote:
> >
> >> 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
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message