Let me give a more precise example: Lang1 ClassA has method m1() marked deprecated.
Lang2 ClassA has no method m1() Lang2 ClassA has method m2() not in Lang2 Classpath=lang1;lang2: I can access m1 but not m2 Classpath=lang2;lang1: I can access m2 but not m1 Does that make sense? Gary -----Original Message----- From: sebb [mailto:[EMAIL PROTECTED] Sent: Friday, June 20, 2008 9:47 AM To: Commons Developers List Subject: Re: [lang] Java 5 On 20/06/2008, Gary Gregory <[EMAIL PROTECTED]> wrote: > Isn't using a new package name the safest thing to do? > > What if: My application depends on lang1 (pre-Java 5 dependency) through a > 3rd party dependency. I want to write my code with lang2 (Java 5 enabled). If > lang2 has deprecations removed, then the classpath order matters: lang1 has > to come first or the 3rd party dependency code will get a > NoSuchMethodException. Surely if the old class is not found in the first jar in the classpath, subsequent jars will also be searched for the class? So CLASSPATH=lang2,lang1 should work for both cases - or am I missing something? > But if lang1 comes first, I cannot use the lang2 version of the class, making > the new features not accessible. > > Should we care about this scenario? > > > Gary > > > -----Original Message----- > From: Henri Yandell [mailto:[EMAIL PROTECTED] > Sent: Friday, June 20, 2008 8:43 AM > To: Commons Developers List > Subject: Re: [lang] Java 5 > > 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. > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
