+1 to move to jdk15 even if it means from ground up... Cal
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] > > -- Regards, Callistus Mendonca
