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]

Reply via email to