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 16:47:07 GMT
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


Mime
View raw message