+1 in moving to JDK 1.5. New contributor, but always wanted to see 1.5 supported libraries in commons.
-v On Fri, Oct 10, 2008 at 9:53 PM, Simone Gianni <[EMAIL PROTECTED]> wrote: > 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] > > -- The first right of human is the right of EGO. -- http://www.xperienceexperience.blogspot.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
