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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: >>> >>> >>>> Resurrecting this thread from 3.5 months ago as my >>>> itch is returning: >>>> >>>> --- Niall Pemberton <[EMAIL PROTECTED]> wrote: >>>> >>>> >>>> >>>>> On Fri, Jun 20, 2008 at 4:42 PM, Henri Yandell >>>>> <[EMAIL PROTECTED]> wrote: >>>>> >>>>> >>>>>> On Thu, Jun 12, 2008 at 5:05 AM, sebb >>>>>> >>>>>> >>>>> <[EMAIL PROTECTED]> wrote: >>>>> >>>>> >>>>>>> On 12/06/2008, James Carman >>>>>>> >>>>>>> >>>>> <[EMAIL PROTECTED]> wrote: >>>>> >>>>> >>>>>>>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton >>>>>>>> >>>>>>>> <[EMAIL PROTECTED]> 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: >>>>> [EMAIL PROTECTED] >>>>> For additional commands, e-mail: >>>>> [EMAIL PROTECTED] >>>>> >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> -- >> Simone Gianni CEO Semeru s.r.l. Apache Committer >> MALE human being programming a computer http://www.simonegianni.it/ >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Simone Gianni CEO Semeru s.r.l. Apache Committer MALE human being programming a computer http://www.simonegianni.it/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
