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]
