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.
+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 <[EMAIL PROTECTED]> wrote:
> Yes, I do agree, but again I'm completely non binding. Migrating code to
> new packages (or new classnames) where
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
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 <[
+1 to move to jdk15 even if it means from ground up...
Cal
On Fri, Oct 10, 2008 at 11:07 AM, Simone Gianni <[EMAIL PROTECTED]> 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
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 man
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 <[EMAI
Resurrecting this thread from 3.5 months ago as my
itch is returning:
--- Niall Pemberton <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 20, 2008 at 4:42 PM, Henri Yandell
> <[EMAIL PROTECTED]> wrote:
> > On Thu, Jun 12, 2008 at 5:05 AM, sebb
> <[EMAIL PROTECTED]> wrote:
> >> On 12/06/2008, James Carma
Good plain from Niall IMO.
Gary
-Original Message-
From: Niall Pemberton [mailto:[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> wrote:
> On Thu, Jun
On Fri, Jun 20, 2008 at 4:42 PM, Henri Yandell <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 5:05 AM, sebb <[EMAIL PROTECTED]> wrote:
>> On 12/06/2008, James Carman <[EMAIL PROTECTED]> wrote:
>>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>>>
>>> <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>
On Fri, Jun 20, 2008 at 12:47 PM, sebb <[EMAIL PROTECTED]> wrote:
> On 20/06/2008, Gary Gregory <[EMAIL PROTECTED]> wrote:
>> Isn't using a new package name the safest thing to do?
>>
>> What if: My application depends on lang1 (pre-Java 5 dependency) through a
>> 3rd party dependency. I want to
> From: sebb [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 20, 2008 9:47 AM
> To: Commons Developers List
> Subject: Re: [lang] Java 5
>
> On 20/06/2008, Gary Gregory <[EMAIL PROTECTED]> wrote:
> > Isn't using a new package name the safest thing to do?
&
-Original Message-
From: sebb [mailto:[EMAIL PROTECTED]
Sent: Friday, June 20, 2008 9:47 AM
To: Commons Developers List
Subject: Re: [lang] Java 5
On 20/06/2008, Gary Gregory <[EMAIL PROTECTED]> wrote:
> Isn't using a new package name the safest thing to do?
>
> What if: My ap
l Message-
> From: Henri Yandell [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 20, 2008 8:43 AM
> To: Commons Developers List
> Subject: Re: [lang] Java 5
>
> On Thu, Jun 12, 2008 at 5:05 AM, sebb <[EMAIL PROTECTED]> wrote:
> > On 12/06/2008, Ja
ECTED]
Sent: Friday, June 20, 2008 8:43 AM
To: Commons Developers List
Subject: Re: [lang] Java 5
On Thu, Jun 12, 2008 at 5:05 AM, sebb <[EMAIL PROTECTED]> wrote:
> On 12/06/2008, James Carman <[EMAIL PROTECTED]> wrote:
>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>&
On Thu, Jun 12, 2008 at 5:05 AM, sebb <[EMAIL PROTECTED]> wrote:
> On 12/06/2008, James Carman <[EMAIL PROTECTED]> wrote:
>> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>>
>> <[EMAIL PROTECTED]> wrote:
>>
>>
>> >> Do you mean that the removal of the enums would mean that we have to
>> >> chan
Nacho Gonzalez Mac Dowell escribió:
simon escribió:
On Fri, 2008-06-13 at 20:19 +0200, Nacho Gonzalez Mac Dowell wrote:
[EMAIL PROTECTED] escribió:
Tom Schindl schrieb:
I can feel your pain. Thank god I'm using OSGi and can declare my
dependencies explicitly :-)
Yep
simon escribió:
On Fri, 2008-06-13 at 20:19 +0200, Nacho Gonzalez Mac Dowell wrote:
[EMAIL PROTECTED] 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
On Wed, Jun 11, 2008 at 1:10 PM, Matt Benson <[EMAIL PROTECTED]> 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
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
On Fri, 2008-06-13 at 20:19 +0200, Nacho Gonzalez Mac Dowell wrote:
> [EMAIL PROTECTED] 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 ju
[EMAIL PROTECTED] 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
Ralph Goers schrieb:
>
>
> James Carman wrote:
>> On Thu, Jun 12, 2008 at 10:45 AM, Ralph Goers
>> <[EMAIL PROTECTED]> 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 li
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
<[EMAIL PROTECTED]> wrote:
>
>
> James Carman wrote:
>>
>> On Thu, Jun 12, 2008 at 10:45 AM, Ralph Goers
>> <[EMAIL PRO
James Carman wrote:
On Thu, Jun 12, 2008 at 10:45 AM, Ralph Goers
<[EMAIL PROTECTED]> 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 techni
On Thu, Jun 12, 2008 at 10:45 AM, Ralph Goers
<[EMAIL PROTECTED]> 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 sou
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,
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 usin
James Carman schrieb:
> On Thu, Jun 12, 2008 at 8:05 AM, sebb <[EMAIL PROTECTED]> 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
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
> Ja
[EMAIL PROTECTED] wrote:
> On Thu, Jun 12, 2008 at 7:11 AM, Niall Pemberton
> <[EMAIL PROTECTED]> 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 deci
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
-
On Thu, Jun 12, 2008 at 8:05 AM, sebb <[EMAIL PROTECTED]> 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 h
On 12/06/2008, James Carman <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>
> <[EMAIL PROTECTED]> wrote:
>
>
> >> Do you mean that the removal of the enums would mean that we have to
> >> change package names?
> >>
> >> Would class/interface removals necessitate a
On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
<[EMAIL PROTECTED]> wrote:
>> Do you mean that the removal of the enums would mean that we have to
>> change package names?
>>
>> Would class/interface removals necessitate a
>> package name change? I haven't really thought that through.
>
> Perhap
On Thu, Jun 12, 2008 at 7:11 AM, Niall Pemberton
<[EMAIL PROTECTED]> 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/Ge
On Thu, Jun 12, 2008 at 12:19 PM, James Carman
<[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 7:11 AM, Niall Pemberton
> <[EMAIL PROTECTED]> 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
>
On Thu, Jun 12, 2008 at 2:46 AM, Ralph Goers <[EMAIL PROTECTED]> 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
On Thu, Jun 12, 2008 at 7:11 AM, Niall Pemberton
<[EMAIL PROTECTED]> 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
On Thu, Jun 12, 2008 at 4:43 AM, James Carman
<[EMAIL PROTECTED]> wrote:
> On Wed, Jun 11, 2008 at 4:10 PM, Matt Benson <[EMAIL PROTECTED]> 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 o
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
* dr
I think we should ask the felix people what can be solved with OSGi and
what can not.
Tom
[EMAIL PROTECTED] 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 i
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
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
[EMAIL PROTECTED] schrieb:
James Carman schrieb:
On Wed, Jun 11,
James Carman schrieb:
> On Wed, Jun 11, 2008 at 4:10 PM, Matt Benson <[EMAIL PROTECTED]> 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.
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 ar
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
On Wed, Jun 11, 2008 at 4:10 PM, Matt Benson <[EMAIL PROTECTED]> 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 for Java 5 and using generics.
Gary
-Original Message-
From: Matt Benson [mailto:[EMAIL PROTECTED]
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
49 matches
Mail list logo
