On 20/06/2008, Gary Gregory <[EMAIL PROTECTED]> wrote: > 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? >
Yes, I see what you mean now. Sorry, I was looking at classes only, and ignoring methods - haven't had any coffee today... > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
