commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [lang] Java 5
Date Fri, 20 Jun 2008 17:05:05 GMT
On 20/06/2008, Gary Gregory <GGregory@seagullsoftware.com> 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:sebbaz@gmail.com]
>  Sent: Friday, June 20, 2008 9:47 AM
>  To: Commons Developers List
>  Subject: Re: [lang] Java 5
>
>  On 20/06/2008, Gary Gregory <GGregory@seagullsoftware.com> 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:flamefew@gmail.com]
>  >  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 <sebbaz@gmail.com> wrote:
>  >  > On 12/06/2008, James Carman <james@carmanconsulting.com> wrote:
>  >  >> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>  >  >>
>  >  >> <niall.pemberton@gmail.com> 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: dev-unsubscribe@commons.apache.org
>  >  For additional commands, e-mail: dev-help@commons.apache.org
>  >
>  >
>  >  ---------------------------------------------------------------------
>  >  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  >  For additional commands, e-mail: dev-help@commons.apache.org
>  >
>  >
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message