You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Matt Benson <gu...@yahoo.com> on 2008/06/11 22:10:24 UTC
[lang] Java 5
There is a JIRA item for using generics, and another
for varargs. Additionally it'd probably be nice to
use generics-level reflection in the oacl.reflect
package. Thoughts on [lang] 3.0 moving to Java 5
source level?
-Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> +1 on generics
> +99 on package-name change.
>
+100
> The ASM project (org.objectweb.asm) changes their API significantly with
> major releases, but do not change the package name. And it causes major
> pain. For example, the following libs all require specific versions of ASM:
> * hibernate
> * drools
> * spring AOP (via cglib)
> * groovy
>
> I've got an app that uses all of the above
Sounds familiar ;-)
Ciao,
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by Holger Hoffstaette <ho...@wizards.de>.
On Fri, 13 Jun 2008 23:19:22 +0200, simon wrote:
> The second part of the "jar hell" problem is dependencies which *are*
> exported as part of a bundle's public API.
>
> For example, a bundle exports a class with this API:
> public boolean isInRange(
> org.apache.lang.math.DoubleRange range, double val);
>
> Now doesn't loading that bundle in an OSGi app limit the entire app to
> having just one common version of lang, just like a non-OSGi app would be?
Bundles and their exported classes can be versioned, with ranges and all;
*without* having to mutilate the package names. At least that is my
understanding, based on reading about the peer class loader stuff.
-h
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by Nacho Gonzalez Mac Dowell <na...@visual-ma.com>.
Nacho Gonzalez Mac Dowell escribió:
> simon escribió:
>> On Fri, 2008-06-13 at 20:19 +0200, Nacho Gonzalez Mac Dowell wrote:
>>
>>> simon.kitching@chello.at escribió:
>>>
>>>> Tom Schindl schrieb:
>>>>
>>>>> I can feel your pain. Thank god I'm using OSGi and can declare my
>>>>> dependencies explicitly :-)
>>>>>
>>>> Yep. Well, it works for those libs that are just internal
>>>> implementation
>>>> details.
>>>>
>>>> I'm not an OSGi expert, but if any exported class contains a public or
>>>> protected method that has type T as a parameter or return type, then
>>>> aren't you again locked into a single application-wide version of the
>>>> lib that provides T?
>>>>
>>> In OSGi you have a different class loader for each bundle making
>>> this possible. Think of Eclipse (currently I work with Equinox).
>>> Bundle (plugin) X can be using ASM version x.x and Bundle Y can use
>>> ASM version x.y. Unless Bundle Y depends on Bundle X and Bundle X
>>> exposes the conflicting packages of ASM (which is a really bad idea)
>>> then you are safe from the headaches you are talking about. Further
>>> on, if you create two bundles with ASM (version x.x and version x.y)
>>> you can specify that Bundle X uses ASM version x.x and that Bundle Y
>>> uses version x.y of ASM with out any problems.
>>>
>>
>> I think this is rephrasing what I said, isn't it? With OSGi,
>> dependencies which are *not* exported as part of a bundle's public api
>> can be completely hidden from other stuff in the app.
>>
>> This solves *half* the "jar hell" problem. Which is nice.
>>
> I don't see why anyone would like to import two different *versions of
> the same* bundles onto a single bundle. As I've said before I use a
> different version of ASM on the very same app. The thing is that I
> have modularised my app so that there is no problem with this. IMHO
> OSGi goes far beyond (truly) solving the "jar hell" problem, like
> forcing you to modularise your app properly. But I think this is
> getting a bit off topic...
Sorry, I meant "I don't see why anyone would like to import two
different *versions of the same* bundles onto a single bundle."
>
> On the other hand, the question is "can you rely on people using
> OSGi?" and the simple answer is no (at least not yet). So it probably
> does make sense to change the package name.
>>
>>>> If so, then OSGi will solve problems for things like ASM which are
>>>> usually pure internal details, but will not solve problems for things
>>>> like commons libs whose types are commonly part of another lib's
>>>> exported API (lang.enums.Enum, lang.math.DoubleRange, etc)...
>>>>
>>> Obviestly, for java reserved words, this is a dead end. You need to
>>> change package names.
>>>
>>
>> Who said anything about reserved words here? The word "enum" is
>> reserved, but neither "enums" nor "Enum" are...
>>
> You are right. Sorry, I just read wrong...
>> The second part of the "jar hell" problem is dependencies which *are*
>> exported as part of a bundle's public API.
>>
>> For example, a bundle exports a class with this API:
>> public boolean isInRange(
>> org.apache.lang.math.DoubleRange range,
>> double val);
>>
>> Now doesn't loading that bundle in an OSGi app limit the entire app to
>> having just one common version of lang, just like a non-OSGi app would
>> be?
>> I'd love to be wrong - it would be cool to solve that problem somehow.
>> But I cannot see how that would be possible. So as far as I know, OSGi
>> solves just half the jar hell problem, and we (lib writers) still need
>> to preserve binary compatibility even between major releases - or change
>> package names.
>>
>> Regards,
>> Simon
>>
> Best regards,
> n
>> ---------------------------------------------------------------------
>> 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
Re: [lang] Java 5
Posted by Nacho Gonzalez Mac Dowell <na...@visual-ma.com>.
simon escribió:
> On Fri, 2008-06-13 at 20:19 +0200, Nacho Gonzalez Mac Dowell wrote:
>
>> simon.kitching@chello.at escribió:
>>
>>> Tom Schindl schrieb:
>>>
>>>
>>>> I can feel your pain. Thank god I'm using OSGi and can declare my
>>>> dependencies explicitly :-)
>>>>
>>>>
>>> Yep. Well, it works for those libs that are just internal implementation
>>> details.
>>>
>>> I'm not an OSGi expert, but if any exported class contains a public or
>>> protected method that has type T as a parameter or return type, then
>>> aren't you again locked into a single application-wide version of the
>>> lib that provides T?
>>>
>>>
>> In OSGi you have a different class loader for each bundle making this
>> possible. Think of Eclipse (currently I work with Equinox). Bundle
>> (plugin) X can be using ASM version x.x and Bundle Y can use ASM version
>> x.y. Unless Bundle Y depends on Bundle X and Bundle X exposes the
>> conflicting packages of ASM (which is a really bad idea) then you are
>> safe from the headaches you are talking about. Further on, if you create
>> two bundles with ASM (version x.x and version x.y) you can specify that
>> Bundle X uses ASM version x.x and that Bundle Y uses version x.y of ASM
>> with out any problems.
>>
>
> I think this is rephrasing what I said, isn't it? With OSGi,
> dependencies which are *not* exported as part of a bundle's public api
> can be completely hidden from other stuff in the app.
>
> This solves *half* the "jar hell" problem. Which is nice.
>
I don't see why anyone would like to import two different bundles onto a
single bundle. As I've said before I use a different version of ASM on
the very same app. The thing is that I have modularised my app so that
there is no problem with this. IMHO OSGi goes far beyond (truly) solving
the "jar hell" problem, like forcing you to modularise your app
properly. But I think this is getting a bit off topic...
On the other hand, the question is "can you rely on people using OSGi?"
and the simple answer is no (at least not yet). So it probably does make
sense to change the package name.
>
>>> If so, then OSGi will solve problems for things like ASM which are
>>> usually pure internal details, but will not solve problems for things
>>> like commons libs whose types are commonly part of another lib's
>>> exported API (lang.enums.Enum, lang.math.DoubleRange, etc)...
>>>
>>>
>> Obviestly, for java reserved words, this is a dead end. You need to
>> change package names.
>>
>
> Who said anything about reserved words here? The word "enum" is
> reserved, but neither "enums" nor "Enum" are...
>
You are right. Sorry, I just read wrong...
> The second part of the "jar hell" problem is dependencies which *are*
> exported as part of a bundle's public API.
>
> For example, a bundle exports a class with this API:
> public boolean isInRange(
> org.apache.lang.math.DoubleRange range,
> double val);
>
> Now doesn't loading that bundle in an OSGi app limit the entire app to
> having just one common version of lang, just like a non-OSGi app would
> be?
>
> I'd love to be wrong - it would be cool to solve that problem somehow.
> But I cannot see how that would be possible. So as far as I know, OSGi
> solves just half the jar hell problem, and we (lib writers) still need
> to preserve binary compatibility even between major releases - or change
> package names.
>
> Regards,
> Simon
>
Best regards,
n
> ---------------------------------------------------------------------
> 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
Re: [lang] Java 5
Posted by simon <si...@chello.at>.
On Fri, 2008-06-13 at 20:19 +0200, Nacho Gonzalez Mac Dowell wrote:
> simon.kitching@chello.at escribió:
> > Tom Schindl schrieb:
> >
> >> I can feel your pain. Thank god I'm using OSGi and can declare my
> >> dependencies explicitly :-)
> >>
> >
> > Yep. Well, it works for those libs that are just internal implementation
> > details.
> >
> > I'm not an OSGi expert, but if any exported class contains a public or
> > protected method that has type T as a parameter or return type, then
> > aren't you again locked into a single application-wide version of the
> > lib that provides T?
> >
> In OSGi you have a different class loader for each bundle making this
> possible. Think of Eclipse (currently I work with Equinox). Bundle
> (plugin) X can be using ASM version x.x and Bundle Y can use ASM version
> x.y. Unless Bundle Y depends on Bundle X and Bundle X exposes the
> conflicting packages of ASM (which is a really bad idea) then you are
> safe from the headaches you are talking about. Further on, if you create
> two bundles with ASM (version x.x and version x.y) you can specify that
> Bundle X uses ASM version x.x and that Bundle Y uses version x.y of ASM
> with out any problems.
I think this is rephrasing what I said, isn't it? With OSGi,
dependencies which are *not* exported as part of a bundle's public api
can be completely hidden from other stuff in the app.
This solves *half* the "jar hell" problem. Which is nice.
>
> > If so, then OSGi will solve problems for things like ASM which are
> > usually pure internal details, but will not solve problems for things
> > like commons libs whose types are commonly part of another lib's
> > exported API (lang.enums.Enum, lang.math.DoubleRange, etc)...
> >
> Obviestly, for java reserved words, this is a dead end. You need to
> change package names.
Who said anything about reserved words here? The word "enum" is
reserved, but neither "enums" nor "Enum" are...
The second part of the "jar hell" problem is dependencies which *are*
exported as part of a bundle's public API.
For example, a bundle exports a class with this API:
public boolean isInRange(
org.apache.lang.math.DoubleRange range,
double val);
Now doesn't loading that bundle in an OSGi app limit the entire app to
having just one common version of lang, just like a non-OSGi app would
be?
I'd love to be wrong - it would be cool to solve that problem somehow.
But I cannot see how that would be possible. So as far as I know, OSGi
solves just half the jar hell problem, and we (lib writers) still need
to preserve binary compatibility even between major releases - or change
package names.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by Nacho Gonzalez Mac Dowell <na...@visual-ma.com>.
simon.kitching@chello.at escribió:
> Tom Schindl schrieb:
>
>> I can feel your pain. Thank god I'm using OSGi and can declare my
>> dependencies explicitly :-)
>>
>
> Yep. Well, it works for those libs that are just internal implementation
> details.
>
> I'm not an OSGi expert, but if any exported class contains a public or
> protected method that has type T as a parameter or return type, then
> aren't you again locked into a single application-wide version of the
> lib that provides T?
>
In OSGi you have a different class loader for each bundle making this
possible. Think of Eclipse (currently I work with Equinox). Bundle
(plugin) X can be using ASM version x.x and Bundle Y can use ASM version
x.y. Unless Bundle Y depends on Bundle X and Bundle X exposes the
conflicting packages of ASM (which is a really bad idea) then you are
safe from the headaches you are talking about. Further on, if you create
two bundles with ASM (version x.x and version x.y) you can specify that
Bundle X uses ASM version x.x and that Bundle Y uses version x.y of ASM
with out any problems.
> If so, then OSGi will solve problems for things like ASM which are
> usually pure internal details, but will not solve problems for things
> like commons libs whose types are commonly part of another lib's
> exported API (lang.enums.Enum, lang.math.DoubleRange, etc)...
>
Obviestly, for java reserved words, this is a dead end. You need to
change package names.
Best regards,
Nacho G. Mac Dowell
> Regards,
> Simon
>
>
> ---------------------------------------------------------------------
> 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
Re: [lang] Java 5
Posted by Tom Schindl <li...@bestsolution.at>.
I think we should ask the felix people what can be solved with OSGi and
what can not.
Tom
simon.kitching@chello.at schrieb:
> Tom Schindl schrieb:
>> I can feel your pain. Thank god I'm using OSGi and can declare my
>> dependencies explicitly :-)
>
> Yep. Well, it works for those libs that are just internal implementation
> details.
>
> I'm not an OSGi expert, but if any exported class contains a public or
> protected method that has type T as a parameter or return type, then
> aren't you again locked into a single application-wide version of the
> lib that provides T?
>
> If so, then OSGi will solve problems for things like ASM which are
> usually pure internal details, but will not solve problems for things
> like commons libs whose types are commonly part of another lib's
> exported API (lang.enums.Enum, lang.math.DoubleRange, etc)...
>
> Regards,
> Simon
>
>
> ---------------------------------------------------------------------
> 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
Re: [lang] Java 5
Posted by "simon.kitching@chello.at" <si...@chello.at>.
Tom Schindl schrieb:
> I can feel your pain. Thank god I'm using OSGi and can declare my
> dependencies explicitly :-)
Yep. Well, it works for those libs that are just internal implementation
details.
I'm not an OSGi expert, but if any exported class contains a public or
protected method that has type T as a parameter or return type, then
aren't you again locked into a single application-wide version of the
lib that provides T?
If so, then OSGi will solve problems for things like ASM which are
usually pure internal details, but will not solve problems for things
like commons libs whose types are commonly part of another lib's
exported API (lang.enums.Enum, lang.math.DoubleRange, etc)...
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by Tom Schindl <li...@bestsolution.at>.
I can feel your pain. Thank god I'm using OSGi and can declare my
dependencies explicitly :-)
I'm also +1 for changing the package name because one can not assume
that everybody is using Felix, Equinox or other OSGi-Envs.
Tom
simon.kitching@chello.at schrieb:
> James Carman schrieb:
>> On Wed, Jun 11, 2008 at 4:10 PM, Matt Benson <gu...@yahoo.com> wrote:
>>
>>> There is a JIRA item for using generics, and another
>>> for varargs. Additionally it'd probably be nice to
>>> use generics-level reflection in the oacl.reflect
>>> package. Thoughts on [lang] 3.0 moving to Java 5
>>> source level?
>>>
>> +1, but I think we need to consider changing the package names (I know
>> you folks are sick of me saying that) if the API is going to change
>> that drastically.
>>
>
> +1 on generics
> +99 on package-name change.
>
> The ASM project (org.objectweb.asm) changes their API significantly with
> major releases, but do not change the package name. And it causes major
> pain. For example, the following libs all require specific versions of ASM:
> * hibernate
> * drools
> * spring AOP (via cglib)
> * groovy
>
> I've got an app that uses all of the above, and it was very difficult to
> get it working. The only thing that saved me is that the groovy and
> cglib projects provide variants that repackage ASM internally (renaming
> the package). Even with that, I'm still stuck on asm 2.2.3 for my code
> when I'd rather be using 3.1.x, just because I cannot use 3.1.x without
> breaking one of the other libs I need.
>
> So if a new project release is not backwards-compatible, please change
> the package name.
>
> Regards,
> Simon
>
>
> ---------------------------------------------------------------------
> 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
Re: [lang] Java 5
Posted by "simon.kitching@chello.at" <si...@chello.at>.
James Carman schrieb:
> On Wed, Jun 11, 2008 at 4:10 PM, Matt Benson <gu...@yahoo.com> wrote:
>
>> There is a JIRA item for using generics, and another
>> for varargs. Additionally it'd probably be nice to
>> use generics-level reflection in the oacl.reflect
>> package. Thoughts on [lang] 3.0 moving to Java 5
>> source level?
>>
>
> +1, but I think we need to consider changing the package names (I know
> you folks are sick of me saying that) if the API is going to change
> that drastically.
>
+1 on generics
+99 on package-name change.
The ASM project (org.objectweb.asm) changes their API significantly with
major releases, but do not change the package name. And it causes major
pain. For example, the following libs all require specific versions of ASM:
* hibernate
* drools
* spring AOP (via cglib)
* groovy
I've got an app that uses all of the above, and it was very difficult to
get it working. The only thing that saved me is that the groovy and
cglib projects provide variants that repackage ASM internally (renaming
the package). Even with that, I'm still stuck on asm 2.2.3 for my code
when I'd rather be using 3.1.x, just because I cannot use 3.1.x without
breaking one of the other libs I need.
So if a new project release is not backwards-compatible, please change
the package name.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Re: [lang] Java 5
Posted by Hendrik Maryns <he...@uni-tuebingen.de>.
Viraj Turakhia schreef:
> +1 in moving to JDK 1.5.
>
> New contributor, but always wanted to see 1.5 supported libraries in commons.
+1, same remark. I generified both Collections and Lang some years ago,
this might be of help, but I never got them compiling in javac, Eclipse
compiles it fine. There is only one warning concerning generics left.
See http://tcl.sfs.uni-tuebingen.de/~hendrik/ (under the first heading).
And currently working on generifying CLI trunk.
H.
--
Hendrik Maryns
Herrenberger Straße 40
D-72070 Tübingen
+49707143783
http://tcl.sfs.uni-tuebingen.de/~hendrik/
=================
www.lieverleven.be Hier kan iedereen wat van leren.
Re: [lang] Java 5
Posted by Viraj Turakhia <vi...@gmail.com>.
+1 in moving to JDK 1.5.
New contributor, but always wanted to see 1.5 supported libraries in commons.
-v
On Fri, Oct 10, 2008 at 9:53 PM, Simone Gianni <si...@apache.org> wrote:
> Yes, I do agree, but again I'm completely non binding. Migrating code to
> new packages (or new classnames) where binary compatibility cannot be
> granted. Unfortunately I cannot foresee how many places would need to be
> refactored to support "double" classes/packages ... internally I mean,
> from a user POV they will call the new class in the the new package if
> they want/need support for jdk5 stuff.
>
> Simone
>
> James Carman wrote:
>> I'm +1 for moving forward, but I would rather change the package name
>> rather than break backward compatibility. There are a lot of
>> libraries out there that depend on commons-* and you may need older
>> versions on your classpath to get them to work.
>>
>> On Fri, Oct 10, 2008 at 11:07 AM, Simone Gianni <si...@apache.org> wrote:
>>
>>> Hi all,
>>> non binding +1 for moving to new versions supporting JDK 5 features,
>>> even if breaking compatibility with older versions and rewriting APIs.
>>> There is a lack of good libraries like lang, beanutils etc.. in the
>>> post-1.5 jdks (see the recent thread i participated in regarding
>>> generics), and many projects are dealing with problems with generics,
>>> enums and so on.
>>>
>>> Simone
>>>
>>> James Carman wrote:
>>>
>>>> Matt, good idea to revive this. Commons needs to come to grips with
>>>> JDK5. It reaches its EOSL on 10/30/2009 and our libraries don't even
>>>> support it yet! We need to come up with an approach to this package
>>>> renaming issue and just move forward.
>>>>
>>>> On Fri, Oct 10, 2008 at 10:44 AM, Matt Benson <gu...@yahoo.com> wrote:
>>>>
>>>>
>>>>> Resurrecting this thread from 3.5 months ago as my
>>>>> itch is returning:
>>>>>
>>>>> --- Niall Pemberton <ni...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On Fri, Jun 20, 2008 at 4:42 PM, Henri Yandell
>>>>>> <fl...@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>> On Thu, Jun 12, 2008 at 5:05 AM, sebb
>>>>>>>
>>>>>>>
>>>>>> <se...@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>>> On 12/06/2008, James Carman
>>>>>>>>
>>>>>>>>
>>>>>> <ja...@carmanconsulting.com> wrote:
>>>>>>
>>>>>>
>>>>>>>>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>>>>>>>>>
>>>>>>>>> <ni...@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.
>>>>>>>
>>>>>>>
>>>>>> *If* lang2 breaks compatibility, then IMO we should
>>>>>> use a new package
>>>>>> name, but moving to JDK 1.5 minimum doesn't
>>>>>> necessarily dictate that
>>>>>> (assuming that we release a compatibility jar for
>>>>>> the enum package
>>>>>> which has to be removed). IMO it would be better to
>>>>>> go through putting
>>>>>> in the JDK 1.5 features that don't break
>>>>>> compatibility and building up
>>>>>> a list of possible changes that do. Then we make the
>>>>>> decision on
>>>>>> whether compatibility-breaking features seem worth
>>>>>> it. If it is, then
>>>>>> lets go all the way, remove deprecations, change the
>>>>>> package name and
>>>>>> put them in. If not, then lets leave the package
>>>>>> name and
>>>>>> deprecations. We've had a similar discussion over
>>>>>> Commons IO and IMO
>>>>>> so far nothing has come up that seems worth the
>>>>>> whole sale package
>>>>>> name change - so I think making the decision first,
>>>>>> without any JDK
>>>>>> 1.5+ features on the table for consideration is a
>>>>>> mistake.
>>>>>>
>>>>>>
>>>>> Let's see, adding generics shouldn't break
>>>>> compatibility; would varargs? Beyond that anything
>>>>> _added_ doesn't break compatibility because we're
>>>>> talking about existing code with drop-in jar
>>>>> replacement, right? Have I correctly outlined the
>>>>> differences between breaking and non-breaking changes
>>>>> in this context? If so, I'd like to go ahead and
>>>>> start with the plan. More likely I've missed
>>>>> something; let's flush it out.
>>>>>
>>>>> -Matt
>>>>>
>>>>>
>>>>>
>>>>>> Niall
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 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
>>>>
>>>>
>>>>
>>> --
>>> Simone Gianni CEO Semeru s.r.l. Apache Committer
>>> MALE human being programming a computer http://www.simonegianni.it/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
>
> --
> Simone Gianni CEO Semeru s.r.l. Apache Committer
> MALE human being programming a computer http://www.simonegianni.it/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
The first right of human is the right of EGO.
--
http://www.xperienceexperience.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by Simone Gianni <si...@apache.org>.
Yes, I do agree, but again I'm completely non binding. Migrating code to
new packages (or new classnames) where binary compatibility cannot be
granted. Unfortunately I cannot foresee how many places would need to be
refactored to support "double" classes/packages ... internally I mean,
from a user POV they will call the new class in the the new package if
they want/need support for jdk5 stuff.
Simone
James Carman wrote:
> I'm +1 for moving forward, but I would rather change the package name
> rather than break backward compatibility. There are a lot of
> libraries out there that depend on commons-* and you may need older
> versions on your classpath to get them to work.
>
> On Fri, Oct 10, 2008 at 11:07 AM, Simone Gianni <si...@apache.org> wrote:
>
>> Hi all,
>> non binding +1 for moving to new versions supporting JDK 5 features,
>> even if breaking compatibility with older versions and rewriting APIs.
>> There is a lack of good libraries like lang, beanutils etc.. in the
>> post-1.5 jdks (see the recent thread i participated in regarding
>> generics), and many projects are dealing with problems with generics,
>> enums and so on.
>>
>> Simone
>>
>> James Carman wrote:
>>
>>> Matt, good idea to revive this. Commons needs to come to grips with
>>> JDK5. It reaches its EOSL on 10/30/2009 and our libraries don't even
>>> support it yet! We need to come up with an approach to this package
>>> renaming issue and just move forward.
>>>
>>> On Fri, Oct 10, 2008 at 10:44 AM, Matt Benson <gu...@yahoo.com> wrote:
>>>
>>>
>>>> Resurrecting this thread from 3.5 months ago as my
>>>> itch is returning:
>>>>
>>>> --- Niall Pemberton <ni...@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>>> On Fri, Jun 20, 2008 at 4:42 PM, Henri Yandell
>>>>> <fl...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>> On Thu, Jun 12, 2008 at 5:05 AM, sebb
>>>>>>
>>>>>>
>>>>> <se...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>>> On 12/06/2008, James Carman
>>>>>>>
>>>>>>>
>>>>> <ja...@carmanconsulting.com> wrote:
>>>>>
>>>>>
>>>>>>>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>>>>>>>>
>>>>>>>> <ni...@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.
>>>>>>
>>>>>>
>>>>> *If* lang2 breaks compatibility, then IMO we should
>>>>> use a new package
>>>>> name, but moving to JDK 1.5 minimum doesn't
>>>>> necessarily dictate that
>>>>> (assuming that we release a compatibility jar for
>>>>> the enum package
>>>>> which has to be removed). IMO it would be better to
>>>>> go through putting
>>>>> in the JDK 1.5 features that don't break
>>>>> compatibility and building up
>>>>> a list of possible changes that do. Then we make the
>>>>> decision on
>>>>> whether compatibility-breaking features seem worth
>>>>> it. If it is, then
>>>>> lets go all the way, remove deprecations, change the
>>>>> package name and
>>>>> put them in. If not, then lets leave the package
>>>>> name and
>>>>> deprecations. We've had a similar discussion over
>>>>> Commons IO and IMO
>>>>> so far nothing has come up that seems worth the
>>>>> whole sale package
>>>>> name change - so I think making the decision first,
>>>>> without any JDK
>>>>> 1.5+ features on the table for consideration is a
>>>>> mistake.
>>>>>
>>>>>
>>>> Let's see, adding generics shouldn't break
>>>> compatibility; would varargs? Beyond that anything
>>>> _added_ doesn't break compatibility because we're
>>>> talking about existing code with drop-in jar
>>>> replacement, right? Have I correctly outlined the
>>>> differences between breaking and non-breaking changes
>>>> in this context? If so, I'd like to go ahead and
>>>> start with the plan. More likely I've missed
>>>> something; let's flush it out.
>>>>
>>>> -Matt
>>>>
>>>>
>>>>
>>>>> Niall
>>>>>
>>>>>
>>>>>
>>>>>> 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
>>>
>>>
>>>
>> --
>> Simone Gianni CEO Semeru s.r.l. Apache Committer
>> MALE human being programming a computer http://www.simonegianni.it/
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
--
Simone Gianni CEO Semeru s.r.l. Apache Committer
MALE human being programming a computer http://www.simonegianni.it/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by James Carman <ja...@carmanconsulting.com>.
I'm +1 for moving forward, but I would rather change the package name
rather than break backward compatibility. There are a lot of
libraries out there that depend on commons-* and you may need older
versions on your classpath to get them to work.
On Fri, Oct 10, 2008 at 11:07 AM, Simone Gianni <si...@apache.org> wrote:
> Hi all,
> non binding +1 for moving to new versions supporting JDK 5 features,
> even if breaking compatibility with older versions and rewriting APIs.
> There is a lack of good libraries like lang, beanutils etc.. in the
> post-1.5 jdks (see the recent thread i participated in regarding
> generics), and many projects are dealing with problems with generics,
> enums and so on.
>
> Simone
>
> James Carman wrote:
>> Matt, good idea to revive this. Commons needs to come to grips with
>> JDK5. It reaches its EOSL on 10/30/2009 and our libraries don't even
>> support it yet! We need to come up with an approach to this package
>> renaming issue and just move forward.
>>
>> On Fri, Oct 10, 2008 at 10:44 AM, Matt Benson <gu...@yahoo.com> wrote:
>>
>>> Resurrecting this thread from 3.5 months ago as my
>>> itch is returning:
>>>
>>> --- Niall Pemberton <ni...@gmail.com> wrote:
>>>
>>>
>>>> On Fri, Jun 20, 2008 at 4:42 PM, Henri Yandell
>>>> <fl...@gmail.com> wrote:
>>>>
>>>>> On Thu, Jun 12, 2008 at 5:05 AM, sebb
>>>>>
>>>> <se...@gmail.com> wrote:
>>>>
>>>>>> On 12/06/2008, James Carman
>>>>>>
>>>> <ja...@carmanconsulting.com> wrote:
>>>>
>>>>>>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>>>>>>>
>>>>>>> <ni...@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.
>>>>>
>>>> *If* lang2 breaks compatibility, then IMO we should
>>>> use a new package
>>>> name, but moving to JDK 1.5 minimum doesn't
>>>> necessarily dictate that
>>>> (assuming that we release a compatibility jar for
>>>> the enum package
>>>> which has to be removed). IMO it would be better to
>>>> go through putting
>>>> in the JDK 1.5 features that don't break
>>>> compatibility and building up
>>>> a list of possible changes that do. Then we make the
>>>> decision on
>>>> whether compatibility-breaking features seem worth
>>>> it. If it is, then
>>>> lets go all the way, remove deprecations, change the
>>>> package name and
>>>> put them in. If not, then lets leave the package
>>>> name and
>>>> deprecations. We've had a similar discussion over
>>>> Commons IO and IMO
>>>> so far nothing has come up that seems worth the
>>>> whole sale package
>>>> name change - so I think making the decision first,
>>>> without any JDK
>>>> 1.5+ features on the table for consideration is a
>>>> mistake.
>>>>
>>> Let's see, adding generics shouldn't break
>>> compatibility; would varargs? Beyond that anything
>>> _added_ doesn't break compatibility because we're
>>> talking about existing code with drop-in jar
>>> replacement, right? Have I correctly outlined the
>>> differences between breaking and non-breaking changes
>>> in this context? If so, I'd like to go ahead and
>>> start with the plan. More likely I've missed
>>> something; let's flush it out.
>>>
>>> -Matt
>>>
>>>
>>>> Niall
>>>>
>>>>
>>>>> 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
>>
>>
>
>
> --
> Simone Gianni CEO Semeru s.r.l. Apache Committer
> MALE human being programming a computer http://www.simonegianni.it/
>
>
> ---------------------------------------------------------------------
> 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
Re: [lang] Java 5
Posted by Callistus Mendonca <ca...@gmail.com>.
+1 to move to jdk15 even if it means from ground up...
Cal
On Fri, Oct 10, 2008 at 11:07 AM, Simone Gianni <si...@apache.org> wrote:
> Hi all,
> non binding +1 for moving to new versions supporting JDK 5 features,
> even if breaking compatibility with older versions and rewriting APIs.
> There is a lack of good libraries like lang, beanutils etc.. in the
> post-1.5 jdks (see the recent thread i participated in regarding
> generics), and many projects are dealing with problems with generics,
> enums and so on.
>
> Simone
>
> James Carman wrote:
> > Matt, good idea to revive this. Commons needs to come to grips with
> > JDK5. It reaches its EOSL on 10/30/2009 and our libraries don't even
> > support it yet! We need to come up with an approach to this package
> > renaming issue and just move forward.
> >
> > On Fri, Oct 10, 2008 at 10:44 AM, Matt Benson <gu...@yahoo.com>
> wrote:
> >
> >> Resurrecting this thread from 3.5 months ago as my
> >> itch is returning:
> >>
> >> --- Niall Pemberton <ni...@gmail.com> wrote:
> >>
> >>
> >>> On Fri, Jun 20, 2008 at 4:42 PM, Henri Yandell
> >>> <fl...@gmail.com> wrote:
> >>>
> >>>> On Thu, Jun 12, 2008 at 5:05 AM, sebb
> >>>>
> >>> <se...@gmail.com> wrote:
> >>>
> >>>>> On 12/06/2008, James Carman
> >>>>>
> >>> <ja...@carmanconsulting.com> wrote:
> >>>
> >>>>>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
> >>>>>>
> >>>>>> <ni...@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.
> >>>>
> >>> *If* lang2 breaks compatibility, then IMO we should
> >>> use a new package
> >>> name, but moving to JDK 1.5 minimum doesn't
> >>> necessarily dictate that
> >>> (assuming that we release a compatibility jar for
> >>> the enum package
> >>> which has to be removed). IMO it would be better to
> >>> go through putting
> >>> in the JDK 1.5 features that don't break
> >>> compatibility and building up
> >>> a list of possible changes that do. Then we make the
> >>> decision on
> >>> whether compatibility-breaking features seem worth
> >>> it. If it is, then
> >>> lets go all the way, remove deprecations, change the
> >>> package name and
> >>> put them in. If not, then lets leave the package
> >>> name and
> >>> deprecations. We've had a similar discussion over
> >>> Commons IO and IMO
> >>> so far nothing has come up that seems worth the
> >>> whole sale package
> >>> name change - so I think making the decision first,
> >>> without any JDK
> >>> 1.5+ features on the table for consideration is a
> >>> mistake.
> >>>
> >> Let's see, adding generics shouldn't break
> >> compatibility; would varargs? Beyond that anything
> >> _added_ doesn't break compatibility because we're
> >> talking about existing code with drop-in jar
> >> replacement, right? Have I correctly outlined the
> >> differences between breaking and non-breaking changes
> >> in this context? If so, I'd like to go ahead and
> >> start with the plan. More likely I've missed
> >> something; let's flush it out.
> >>
> >> -Matt
> >>
> >>
> >>> Niall
> >>>
> >>>
> >>>> 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
> >
> >
>
>
> --
> Simone Gianni CEO Semeru s.r.l. Apache Committer
> MALE human being programming a computer http://www.simonegianni.it/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Regards,
Callistus Mendonca
Re: [lang] Java 5
Posted by Simone Gianni <si...@apache.org>.
Hi all,
non binding +1 for moving to new versions supporting JDK 5 features,
even if breaking compatibility with older versions and rewriting APIs.
There is a lack of good libraries like lang, beanutils etc.. in the
post-1.5 jdks (see the recent thread i participated in regarding
generics), and many projects are dealing with problems with generics,
enums and so on.
Simone
James Carman wrote:
> Matt, good idea to revive this. Commons needs to come to grips with
> JDK5. It reaches its EOSL on 10/30/2009 and our libraries don't even
> support it yet! We need to come up with an approach to this package
> renaming issue and just move forward.
>
> On Fri, Oct 10, 2008 at 10:44 AM, Matt Benson <gu...@yahoo.com> wrote:
>
>> Resurrecting this thread from 3.5 months ago as my
>> itch is returning:
>>
>> --- Niall Pemberton <ni...@gmail.com> wrote:
>>
>>
>>> On Fri, Jun 20, 2008 at 4:42 PM, Henri Yandell
>>> <fl...@gmail.com> wrote:
>>>
>>>> On Thu, Jun 12, 2008 at 5:05 AM, sebb
>>>>
>>> <se...@gmail.com> wrote:
>>>
>>>>> On 12/06/2008, James Carman
>>>>>
>>> <ja...@carmanconsulting.com> wrote:
>>>
>>>>>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>>>>>>
>>>>>> <ni...@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.
>>>>
>>> *If* lang2 breaks compatibility, then IMO we should
>>> use a new package
>>> name, but moving to JDK 1.5 minimum doesn't
>>> necessarily dictate that
>>> (assuming that we release a compatibility jar for
>>> the enum package
>>> which has to be removed). IMO it would be better to
>>> go through putting
>>> in the JDK 1.5 features that don't break
>>> compatibility and building up
>>> a list of possible changes that do. Then we make the
>>> decision on
>>> whether compatibility-breaking features seem worth
>>> it. If it is, then
>>> lets go all the way, remove deprecations, change the
>>> package name and
>>> put them in. If not, then lets leave the package
>>> name and
>>> deprecations. We've had a similar discussion over
>>> Commons IO and IMO
>>> so far nothing has come up that seems worth the
>>> whole sale package
>>> name change - so I think making the decision first,
>>> without any JDK
>>> 1.5+ features on the table for consideration is a
>>> mistake.
>>>
>> Let's see, adding generics shouldn't break
>> compatibility; would varargs? Beyond that anything
>> _added_ doesn't break compatibility because we're
>> talking about existing code with drop-in jar
>> replacement, right? Have I correctly outlined the
>> differences between breaking and non-breaking changes
>> in this context? If so, I'd like to go ahead and
>> start with the plan. More likely I've missed
>> something; let's flush it out.
>>
>> -Matt
>>
>>
>>> Niall
>>>
>>>
>>>> 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
>
>
--
Simone Gianni CEO Semeru s.r.l. Apache Committer
MALE human being programming a computer http://www.simonegianni.it/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by James Carman <ja...@carmanconsulting.com>.
Matt, good idea to revive this. Commons needs to come to grips with
JDK5. It reaches its EOSL on 10/30/2009 and our libraries don't even
support it yet! We need to come up with an approach to this package
renaming issue and just move forward.
On Fri, Oct 10, 2008 at 10:44 AM, Matt Benson <gu...@yahoo.com> wrote:
> Resurrecting this thread from 3.5 months ago as my
> itch is returning:
>
> --- Niall Pemberton <ni...@gmail.com> wrote:
>
>> On Fri, Jun 20, 2008 at 4:42 PM, Henri Yandell
>> <fl...@gmail.com> wrote:
>> > On Thu, Jun 12, 2008 at 5:05 AM, sebb
>> <se...@gmail.com> wrote:
>> >> On 12/06/2008, James Carman
>> <ja...@carmanconsulting.com> wrote:
>> >>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>> >>>
>> >>> <ni...@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.
>>
>> *If* lang2 breaks compatibility, then IMO we should
>> use a new package
>> name, but moving to JDK 1.5 minimum doesn't
>> necessarily dictate that
>> (assuming that we release a compatibility jar for
>> the enum package
>> which has to be removed). IMO it would be better to
>> go through putting
>> in the JDK 1.5 features that don't break
>> compatibility and building up
>> a list of possible changes that do. Then we make the
>> decision on
>> whether compatibility-breaking features seem worth
>> it. If it is, then
>> lets go all the way, remove deprecations, change the
>> package name and
>> put them in. If not, then lets leave the package
>> name and
>> deprecations. We've had a similar discussion over
>> Commons IO and IMO
>> so far nothing has come up that seems worth the
>> whole sale package
>> name change - so I think making the decision first,
>> without any JDK
>> 1.5+ features on the table for consideration is a
>> mistake.
>
> Let's see, adding generics shouldn't break
> compatibility; would varargs? Beyond that anything
> _added_ doesn't break compatibility because we're
> talking about existing code with drop-in jar
> replacement, right? Have I correctly outlined the
> differences between breaking and non-breaking changes
> in this context? If so, I'd like to go ahead and
> start with the plan. More likely I've missed
> something; let's flush it out.
>
> -Matt
>
>>
>> Niall
>>
>> > 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
RE: [lang] Java 5
Posted by Gary Gregory <GG...@seagullsoftware.com>.
Good plain from Niall IMO.
Gary
-----Original Message-----
From: Niall Pemberton [mailto:niall.pemberton@gmail.com]
Sent: Friday, June 20, 2008 11:21 AM
To: Commons Developers List
Subject: Re: [lang] Java 5
On Fri, Jun 20, 2008 at 4:42 PM, Henri Yandell <fl...@gmail.com> wrote:
> On Thu, Jun 12, 2008 at 5:05 AM, sebb <se...@gmail.com> wrote:
>> On 12/06/2008, James Carman <ja...@carmanconsulting.com> wrote:
>>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>>>
>>> <ni...@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.
*If* lang2 breaks compatibility, then IMO we should use a new package
name, but moving to JDK 1.5 minimum doesn't necessarily dictate that
(assuming that we release a compatibility jar for the enum package
which has to be removed). IMO it would be better to go through putting
in the JDK 1.5 features that don't break compatibility and building up
a list of possible changes that do. Then we make the decision on
whether compatibility-breaking features seem worth it. If it is, then
lets go all the way, remove deprecations, change the package name and
put them in. If not, then lets leave the package name and
deprecations. We've had a similar discussion over Commons IO and IMO
so far nothing has come up that seems worth the whole sale package
name change - so I think making the decision first, without any JDK
1.5+ features on the table for consideration is a mistake.
Niall
> 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
Re: [lang] Java 5
Posted by Matt Benson <gu...@yahoo.com>.
Resurrecting this thread from 3.5 months ago as my
itch is returning:
--- Niall Pemberton <ni...@gmail.com> wrote:
> On Fri, Jun 20, 2008 at 4:42 PM, Henri Yandell
> <fl...@gmail.com> wrote:
> > On Thu, Jun 12, 2008 at 5:05 AM, sebb
> <se...@gmail.com> wrote:
> >> On 12/06/2008, James Carman
> <ja...@carmanconsulting.com> wrote:
> >>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
> >>>
> >>> <ni...@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.
>
> *If* lang2 breaks compatibility, then IMO we should
> use a new package
> name, but moving to JDK 1.5 minimum doesn't
> necessarily dictate that
> (assuming that we release a compatibility jar for
> the enum package
> which has to be removed). IMO it would be better to
> go through putting
> in the JDK 1.5 features that don't break
> compatibility and building up
> a list of possible changes that do. Then we make the
> decision on
> whether compatibility-breaking features seem worth
> it. If it is, then
> lets go all the way, remove deprecations, change the
> package name and
> put them in. If not, then lets leave the package
> name and
> deprecations. We've had a similar discussion over
> Commons IO and IMO
> so far nothing has come up that seems worth the
> whole sale package
> name change - so I think making the decision first,
> without any JDK
> 1.5+ features on the table for consideration is a
> mistake.
Let's see, adding generics shouldn't break
compatibility; would varargs? Beyond that anything
_added_ doesn't break compatibility because we're
talking about existing code with drop-in jar
replacement, right? Have I correctly outlined the
differences between breaking and non-breaking changes
in this context? If so, I'd like to go ahead and
start with the plan. More likely I've missed
something; let's flush it out.
-Matt
>
> Niall
>
> > 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
Re: [lang] Java 5
Posted by Niall Pemberton <ni...@gmail.com>.
On Fri, Jun 20, 2008 at 4:42 PM, Henri Yandell <fl...@gmail.com> wrote:
> On Thu, Jun 12, 2008 at 5:05 AM, sebb <se...@gmail.com> wrote:
>> On 12/06/2008, James Carman <ja...@carmanconsulting.com> wrote:
>>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>>>
>>> <ni...@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.
*If* lang2 breaks compatibility, then IMO we should use a new package
name, but moving to JDK 1.5 minimum doesn't necessarily dictate that
(assuming that we release a compatibility jar for the enum package
which has to be removed). IMO it would be better to go through putting
in the JDK 1.5 features that don't break compatibility and building up
a list of possible changes that do. Then we make the decision on
whether compatibility-breaking features seem worth it. If it is, then
lets go all the way, remove deprecations, change the package name and
put them in. If not, then lets leave the package name and
deprecations. We've had a similar discussion over Commons IO and IMO
so far nothing has come up that seems worth the whole sale package
name change - so I think making the decision first, without any JDK
1.5+ features on the table for consideration is a mistake.
Niall
> 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
Re: [lang] Java 5
Posted by James Carman <ja...@carmanconsulting.com>.
On Fri, Jun 20, 2008 at 12:47 PM, sebb <se...@gmail.com> wrote:
> On 20/06/2008, Gary Gregory <GG...@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?
What about in the case of a webapp, though? You can't really control
the classpath order (unless you change the jar names I guess).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by sebb <se...@gmail.com>.
On 20/06/2008, Gary Gregory <GG...@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 <GG...@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 <se...@gmail.com> wrote:
> > > On 12/06/2008, James Carman <ja...@carmanconsulting.com> wrote:
> > >> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
> > >>
> > >> <ni...@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
RE: [lang] Java 5
Posted by Gary Gregory <GG...@seagullsoftware.com>.
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: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 <GG...@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 <se...@gmail.com> wrote:
> > On 12/06/2008, James Carman <ja...@carmanconsulting.com> wrote:
> >> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
> >>
> >> <ni...@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
Re: [lang] Java 5
Posted by sebb <se...@gmail.com>.
On 20/06/2008, Gary Gregory <GG...@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 <se...@gmail.com> wrote:
> > On 12/06/2008, James Carman <ja...@carmanconsulting.com> wrote:
> >> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
> >>
> >> <ni...@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
RE: [lang] Java 5
Posted by Gary Gregory <GG...@seagullsoftware.com>.
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. 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 <se...@gmail.com> wrote:
> On 12/06/2008, James Carman <ja...@carmanconsulting.com> wrote:
>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>>
>> <ni...@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
Re: [lang] Java 5
Posted by Henri Yandell <fl...@gmail.com>.
On Thu, Jun 12, 2008 at 5:05 AM, sebb <se...@gmail.com> wrote:
> On 12/06/2008, James Carman <ja...@carmanconsulting.com> wrote:
>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>>
>> <ni...@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
Re: [lang] Java 5
Posted by Tom Schindl <li...@bestsolution.at>.
Well the whole commons stack now has support for OSGi and OSGi provides
a mechanism to not export a package so I'd say one should use the
internal package (e.g. org.apache.commons.lang.internal) for all classes
that have to be public but are not part of the public API.
This is better than using the _ IMHO and in conjunction with a big
comment this makes it as clear as possible.
Another problem are interfaces that are not designed get implemented by
client code. They should be flag as that in a common way (as a side note
eclipse 3.4 provides special javadoc comments for such
classes/interfaces and other helpers to ensure that one does break
binary/source compatility when evolving the API of modules [1] which is
very tricky thing to get right but this doesn't apply to commons I guess
because its not bound to an IDE).
Tom
[1]http://wiki.eclipse.org/Evolving_Java-based_APIs_2
simon.kitching@chello.at schrieb:
> Emmanuel Bourg schrieb:
>> sebb a écrit :
>>
>>> BTW, perhaps Commons should have a similar naming convention for
>>> packages that need to contain public methods, but which are only
>>> intended to be used in Commons libraries.
>> Or a big "DO NOT USE THIS CLASS, RESERVED FOR INTERNAL USE" in the
>> Javadoc ?
> In the MyFaces project, the convention is to use a leading underscore on
> the names of classes that are not intended to be part of the stable
> public API (but cannot be package-scoped for technical reasons), eg
> public class _WidgetUtils {....}
>
> A javadoc comment like the above is also attached, but the leading
> underscore makes these classes really stand out.
>
> Regards,
> Simon
>
>
> ---------------------------------------------------------------------
> 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
Re: [lang] Java 5
Posted by "simon.kitching@chello.at" <si...@chello.at>.
Emmanuel Bourg schrieb:
> sebb a écrit :
>
>> BTW, perhaps Commons should have a similar naming convention for
>> packages that need to contain public methods, but which are only
>> intended to be used in Commons libraries.
>
> Or a big "DO NOT USE THIS CLASS, RESERVED FOR INTERNAL USE" in the
> Javadoc ?
In the MyFaces project, the convention is to use a leading underscore on
the names of classes that are not intended to be part of the stable
public API (but cannot be package-scoped for technical reasons), eg
public class _WidgetUtils {....}
A javadoc comment like the above is also attached, but the leading
underscore makes these classes really stand out.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by Emmanuel Bourg <eb...@apache.org>.
sebb a écrit :
> BTW, perhaps Commons should have a similar naming convention for
> packages that need to contain public methods, but which are only
> intended to be used in Commons libraries.
Or a big "DO NOT USE THIS CLASS, RESERVED FOR INTERNAL USE" in the Javadoc ?
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by "simon.kitching@chello.at" <si...@chello.at>.
James Carman schrieb:
> On Thu, Jun 12, 2008 at 8:05 AM, sebb <se...@gmail.com> wrote:
>
>
>> 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 guess I was thinking of the situation where you'd have two versions
> of the same jar on the classpath. Obviously the fact that an entire
> class/interface is gone would mean that a particular version of a
> library isn't backwards compatible.
>
The problem is that there is usually a reason why the class or interface
was removed.
For example, if there once was a FooListener interface available that
people could attach to their widgets, and it no longer exists, then it
is probably because the rest of the lib is no longer invoking the
listener methods on that interface. So simply providing the old
interface class will fix *binary* compatibility, but will result in a
broken program as the user's objects won't be getting the callbacks it
expects.
Only cases where the removed classes/interfaces were completely
stand-alone and do not interact with the rest of the library does it
make sense to provide copies of the old classes. Which won't be the case
very often.
Oddly, the case of org.apache.commons.lang.enum.* this probably is true.
This code just cannot be compiled with java1.5. However the old lang
project could provide a new jarfile "lang-enum.jar" that just contains
the lang.enum.* classes (compiled with java1.4). This could then be used
together with the new java1.5 version of lang to provide full backwards
compatibility. In this case, I would say that the lang1.5 version would
not need a package-name bump, as (lang15.jar + lang-enum.jar) is a fully
compatible replacement for the old version.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by James Carman <ja...@carmanconsulting.com>.
On Thu, Jun 12, 2008 at 8:05 AM, sebb <se...@gmail.com> wrote:
> 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 guess I was thinking of the situation where you'd have two versions
of the same jar on the classpath. Obviously the fact that an entire
class/interface is gone would mean that a particular version of a
library isn't backwards compatible.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by sebb <se...@gmail.com>.
On 12/06/2008, James Carman <ja...@carmanconsulting.com> wrote:
> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>
> <ni...@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.
If jar X depends on oldMethod() and jar Y requires newMethod() it will
be difficult/impossible to combine jars X and Y in the same
application.
So I would say removals would need a name change.
If the item is not public, then it might be possible to avoid a rename
- depends on whether the item is likely to be used by external
libraries.
Maybe there are some methods/classes etc that are flagged as
"internal" use only, in which case 3rd parties cannot complain if the
APIs change. C.f. the com.sun packages.
BTW, perhaps Commons should have a similar naming convention for
packages that need to contain public methods, but which are only
intended to be used in Commons libraries.
>
> I mentioned it as a conversation starter. I'm not saying it does or
> doesn't. I can be somewhat shortsighted sometimes when it comes to
> situations like this. :) I just hoped other folks who have maybe
> encountered the situation and have a strong opinion one way or the
> other would weigh in.
>
>
> ---------------------------------------------------------------------
> 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
Re: [lang] Java 5
Posted by James Carman <ja...@carmanconsulting.com>.
On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
<ni...@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
>
I mentioned it as a conversation starter. I'm not saying it does or
doesn't. I can be somewhat shortsighted sometimes when it comes to
situations like this. :) I just hoped other folks who have maybe
encountered the situation and have a strong opinion one way or the
other would weigh in.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by Niall Pemberton <ni...@gmail.com>.
On Thu, Jun 12, 2008 at 12:19 PM, James Carman
<ja...@carmanconsulting.com> wrote:
> On Thu, Jun 12, 2008 at 7:11 AM, Niall Pemberton
> <ni...@gmail.com> wrote:
>
>>
>> P.S. Perhaps its a moot point in Lang's case since I guess the
>> deprecated enum package has to be removed to move to a minimum of JDK
>> 1.5.
>
> 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
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by James Carman <ja...@carmanconsulting.com>.
On Thu, Jun 12, 2008 at 7:11 AM, Niall Pemberton
<ni...@gmail.com> wrote:
>
> P.S. Perhaps its a moot point in Lang's case since I guess the
> deprecated enum package has to be removed to move to a minimum of JDK
> 1.5.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by James Carman <ja...@carmanconsulting.com>.
Yes, of course! :) But, who does that anymore? ;) I'm kidding of
course. I know that some vendors only support JDK 1.4 currently.
On Thu, Jun 12, 2008 at 11:16 AM, Ralph Goers
<Ra...@dslextreme.com> wrote:
>
>
> James Carman wrote:
>>
>> On Thu, Jun 12, 2008 at 10:45 AM, Ralph Goers
>> <Ra...@dslextreme.com> wrote:
>>
>>
>>>
>>> This confuses me. Doesn't the fact that since the code will no longer run
>>> on
>>> a pre-1.5 JDK mean that compatibility is broken, even if not a single
>>> line
>>> of code changes? (Yes - I know that we technically only release source so
>>> in
>>> that case it could be recompiled, but I work with Maven). In any case, I
>>> expect that the code will only compile with a 1.5 compiler anyway.
>>>
>>>
>>
>> Just because the new Commons Lang is compiled against 1.5 doesn't mean
>> that older code that depends on it won't be able to use it.
>>
>>
>
> It does if that older code is trying to run in a 1.4 or 1.3 JVM.
>
> ---------------------------------------------------------------------
> 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
Re: [lang] Java 5
Posted by "simon.kitching@chello.at" <si...@chello.at>.
Ralph Goers schrieb:
>
>
> James Carman wrote:
>> On Thu, Jun 12, 2008 at 10:45 AM, Ralph Goers
>> <Ra...@dslextreme.com> wrote:
>>
>>
>>> This confuses me. Doesn't the fact that since the code will no
>>> longer run on
>>> a pre-1.5 JDK mean that compatibility is broken, even if not a
>>> single line
>>> of code changes? (Yes - I know that we technically only release
>>> source so in
>>> that case it could be recompiled, but I work with Maven). In any
>>> case, I
>>> expect that the code will only compile with a 1.5 compiler anyway.
>>>
>>>
>>
>> Just because the new Commons Lang is compiled against 1.5 doesn't mean
>> that older code that depends on it won't be able to use it.
>>
>>
> It does if that older code is trying to run in a 1.4 or 1.3 JVM.
There are two kinds of compatibility:
(a) being able to drop a new lib into an existing system without
changing anything
(b) being able to write a new app combining existing libs
(a) is called a bugfix release. We're not talking about that. And for
anything other than a bugfix release, people should expect to need to
update other bits of their system (including upgrading to a new Java
release) if they want to upgrade to a new lib.
(b) is what we are talking about here. There are cases where people are
left with absolutely *no* possible way of combining a set of libraries
into a single application. This can happen if lib A works *only* with
lang x.x and lib B works *only* with lang y.y, and the two lang versions
have the same package name.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by Ralph Goers <Ra...@dslextreme.com>.
James Carman wrote:
> On Thu, Jun 12, 2008 at 10:45 AM, Ralph Goers
> <Ra...@dslextreme.com> wrote:
>
>
>> This confuses me. Doesn't the fact that since the code will no longer run on
>> a pre-1.5 JDK mean that compatibility is broken, even if not a single line
>> of code changes? (Yes - I know that we technically only release source so in
>> that case it could be recompiled, but I work with Maven). In any case, I
>> expect that the code will only compile with a 1.5 compiler anyway.
>>
>>
>
> Just because the new Commons Lang is compiled against 1.5 doesn't mean
> that older code that depends on it won't be able to use it.
>
>
It does if that older code is trying to run in a 1.4 or 1.3 JVM.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by James Carman <ja...@carmanconsulting.com>.
On Thu, Jun 12, 2008 at 10:45 AM, Ralph Goers
<Ra...@dslextreme.com> wrote:
> This confuses me. Doesn't the fact that since the code will no longer run on
> a pre-1.5 JDK mean that compatibility is broken, even if not a single line
> of code changes? (Yes - I know that we technically only release source so in
> that case it could be recompiled, but I work with Maven). In any case, I
> expect that the code will only compile with a 1.5 compiler anyway.
>
Just because the new Commons Lang is compiled against 1.5 doesn't mean
that older code that depends on it won't be able to use it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by Ralph Goers <Ra...@dslextreme.com>.
James Carman wrote:
>
> Perhaps we need to come up with a standardized versioning strategy for
> Commons projects, then. A simple rule might be that if you're
> breaking compatibility, you have to jump major versions and change
> your package names (I would argue that whenever we jump version
> numbers, we should change package names to match to keep things
> consistent). I keep bringing this up, but it never gets anywhere.
> I'm kind of stubborn like that I guess. :)
>
> If merely jumping to JDK5 language level doesn't break API
> compatibility, then let's not jump to a new major version.
>
>
This confuses me. Doesn't the fact that since the code will no longer
run on a pre-1.5 JDK mean that compatibility is broken, even if not a
single line of code changes? (Yes - I know that we technically only
release source so in that case it could be recompiled, but I work with
Maven). In any case, I expect that the code will only compile with a 1.5
compiler anyway.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [lang] Java 5
Posted by Jörg Schaible <Jo...@Elsag-Solutions.com>.
jcarman@carmanconsulting.com wrote:
> On Thu, Jun 12, 2008 at 7:11 AM, Niall Pemberton
> <ni...@gmail.com> wrote:
>
>> I would agree that for Lang that *if* the API change breaks
>> compatibility, then a package name change would be appropriate - but
>> I think its a mistake in general to start making decisions along the
>> lines JDK 1/5/Generics == package rename BEFORE there are any
>> concrete proposals on the table.
>
> Perhaps we need to come up with a standardized versioning strategy for
> Commons projects, then. A simple rule might be that if you're
> breaking compatibility, you have to jump major versions and change
> your package names (I would argue that whenever we jump version
> numbers, we should change package names to match to keep things
> consistent). I keep bringing this up, but it never gets anywhere.
> I'm kind of stubborn like that I guess. :)
>
> If merely jumping to JDK5 language level doesn't break API
> compatibility, then let's not jump to a new major version.
Well, just to throw in a different thought: Package name change is only necessary if both versions implement types with same names that are incompatible. That is what ASM did and why the problem exists at all. If only one class of 100 is incompatible, it might be better to introduce the new one with a different name instead of renaming the complete package. However, this only applies if the new version is a drop-in replacement. If classes have been removed (like the enum package), it must be still possible then to have both versions in the CP as long as the new one comes first. Nevertheless this scenario is much more difficult to handle and from the maintenace PoV it might be easier to rename the package altogether then.
Therfore - depending on the nature of change - we can either introduce a new class name, rename only a subpackage or do so for the complete project. Additionally we can always ship an additional compatibility package that can be used as complete replacement of an old version in combination with a newer one.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by James Carman <ja...@carmanconsulting.com>.
On Thu, Jun 12, 2008 at 7:11 AM, Niall Pemberton
<ni...@gmail.com> wrote:
> I would agree that for Lang that *if* the API change breaks
> compatibility, then a package name change would be appropriate - but I
> think its a mistake in general to start making decisions along the
> lines JDK 1/5/Generics == package rename BEFORE there are any concrete
> proposals on the table.
Perhaps we need to come up with a standardized versioning strategy for
Commons projects, then. A simple rule might be that if you're
breaking compatibility, you have to jump major versions and change
your package names (I would argue that whenever we jump version
numbers, we should change package names to match to keep things
consistent). I keep bringing this up, but it never gets anywhere.
I'm kind of stubborn like that I guess. :)
If merely jumping to JDK5 language level doesn't break API
compatibility, then let's not jump to a new major version.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by Niall Pemberton <ni...@gmail.com>.
On Thu, Jun 12, 2008 at 4:43 AM, James Carman
<ja...@carmanconsulting.com> wrote:
> On Wed, Jun 11, 2008 at 4:10 PM, Matt Benson <gu...@yahoo.com> wrote:
>> There is a JIRA item for using generics, and another
>> for varargs. Additionally it'd probably be nice to
>> use generics-level reflection in the oacl.reflect
>> package. Thoughts on [lang] 3.0 moving to Java 5
>> source level?
>
> +1, but I think we need to consider changing the package names (I know
> you folks are sick of me saying that) if the API is going to change
> that drastically.
I would agree that for Lang that *if* the API change breaks
compatibility, then a package name change would be appropriate - but I
think its a mistake in general to start making decisions along the
lines JDK 1/5/Generics == package rename BEFORE there are any concrete
proposals on the table.
Niall
P.S. Perhaps its a moot point in Lang's case since I guess the
deprecated enum package has to be removed to move to a minimum of JDK
1.5.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by James Carman <ja...@carmanconsulting.com>.
On Thu, Jun 12, 2008 at 2:46 AM, Ralph Goers <Ra...@dslextreme.com> wrote:
> I haven't been following this list all that long so I'm interested in
> knowing why you want the package names changed. (I apologize in advance to
> those who have already heard this before).
>
Sure. We should probably have a wiki page for this topic (perhaps we
do already?). Anyway, the idea is that if we change the package names
to match the major release version number (so in this case, it'd be
org.apache.commons.lang3.*), then we help avoid "jar hell." The
Apache Commons projects are somewhat unique, in that they're used by a
lot of other projects that, in turn, are used by "users". If Project
X and Project Y both are very popular open source projects, and they
depend on two different (and the key here is incompatible) versions of
Commons Lang, then how do you set up your classpath to keep both
projects happy if you want to use them? Well, if Project X codes to
org.apache.commons.lang and Project Y codes to
org.apache.commons.lang3, then there are no worries. Problem solved.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by Ralph Goers <Ra...@dslextreme.com>.
I haven't been following this list all that long so I'm interested in
knowing why you want the package names changed. (I apologize in advance
to those who have already heard this before).
BTW - I'm +1 on Java 5. Not only for lang but for a bunch of commons
projects.
James Carman wrote:
> On Wed, Jun 11, 2008 at 4:10 PM, Matt Benson <gu...@yahoo.com> wrote:
>
>> There is a JIRA item for using generics, and another
>> for varargs. Additionally it'd probably be nice to
>> use generics-level reflection in the oacl.reflect
>> package. Thoughts on [lang] 3.0 moving to Java 5
>> source level?
>>
>
> +1, but I think we need to consider changing the package names (I know
> you folks are sick of me saying that) if the API is going to change
> that drastically.
>
> ---------------------------------------------------------------------
> 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
Re: [lang] Java 5
Posted by James Carman <ja...@carmanconsulting.com>.
On Wed, Jun 11, 2008 at 4:10 PM, Matt Benson <gu...@yahoo.com> wrote:
> There is a JIRA item for using generics, and another
> for varargs. Additionally it'd probably be nice to
> use generics-level reflection in the oacl.reflect
> package. Thoughts on [lang] 3.0 moving to Java 5
> source level?
+1, but I think we need to consider changing the package names (I know
you folks are sick of me saying that) if the API is going to change
that drastically.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Java 5
Posted by Aaron Zeckoski <aa...@vt.edu>.
I would be happy to see this for lots of the commons projects.
Shouldn't the generics APIs generally be compatible with the current
ones? I have been able to add generics to APIs in the past without
breaking compatibility since they really only come into play at
compile time anyway.
Also, if you are looking for volunteers then I would be happy to help.
-AZ
On Wed, Jun 11, 2008 at 9:10 PM, Matt Benson <gu...@yahoo.com> wrote:
> There is a JIRA item for using generics, and another
> for varargs. Additionally it'd probably be nice to
> use generics-level reflection in the oacl.reflect
> package. Thoughts on [lang] 3.0 moving to Java 5
> source level?
>
> -Matt
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Aaron Zeckoski (aaronz@vt.edu)
Senior Research Engineer - CARET - Cambridge University
[http://bugs.sakaiproject.org/confluence/display/~aaronz/]
Sakai Fellow - [http://aaronz-sakai.blogspot.com/]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [lang] Java 5
Posted by Gary Gregory <GG...@seagullsoftware.com>.
+1 for Java 5 and using generics.
Gary
-----Original Message-----
From: Matt Benson [mailto:gudnabrsam@yahoo.com]
Sent: Wednesday, June 11, 2008 1:10 PM
To: commons Developers List
Subject: [lang] Java 5
There is a JIRA item for using generics, and another
for varargs. Additionally it'd probably be nice to
use generics-level reflection in the oacl.reflect
package. Thoughts on [lang] 3.0 moving to Java 5
source level?
-Matt
---------------------------------------------------------------------
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
Re: [lang] Java 5
Posted by Henri Yandell <fl...@gmail.com>.
On Wed, Jun 11, 2008 at 1:10 PM, Matt Benson <gu...@yahoo.com> wrote:
> There is a JIRA item for using generics, and another
> for varargs. Additionally it'd probably be nice to
> use generics-level reflection in the oacl.reflect
> package. Thoughts on [lang] 3.0 moving to Java 5
> source level?
Reading through the whole thread, I'm +1 to making Lang 3.0 Java 5
specific, to adding new Java 5 features, and to removing deprecated
functionality (ie: the enum package and various other methods), but
not to modifying existing features in a backwards incompatible way.
We also shouldn't remove features that are available in another means
in Java 1.5; ie: the enums package.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org