Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of callistus.mendonca@gmail.com
 designates 74.125.46.155 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=utS4x2zfTYipSVY/7TKzBWbraETyxM2txYWudvpsULWtdv082qbVzdfQfhrygPPSed
         kTW8DaR0mBSDxln8CJXhuw7YRF7rPgzqjDLgKhQHc6dXP+FF4Pki+LNUW2DNTfJf+JbR
         MuMGVYAsmF34Rqeko554uikJGaMnfL2ENd3hM=
Message-ID: <e2e71c600810100859w7b7cff58v3e323ec0777118bb@mail.gmail.com>
Date: Fri, 10 Oct 2008 11:59:12 -0400
From: "Callistus Mendonca" <callistus.mendonca@gmail.com>
To: "Commons Developers List" <dev@commons.apache.org>
Subject: Re: [lang] Java 5
In-Reply-To: <48EF6FB7.2040500@apache.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_78283_18812512.1223654352196"
References: <55afdc850806201120m3d5dd2e0i7c8225b972a1e7de@mail.gmail.com>
	 <454440.59667.qm@web55103.mail.re4.yahoo.com>
	 <f2e8eedf0810100751r270b6954u8a7fece94ef34ba4@mail.gmail.com>
	 <48EF6FB7.2040500@apache.org>

------=_Part_78283_18812512.1223654352196
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

+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

------=_Part_78283_18812512.1223654352196--