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.
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 Carman
[EMAIL
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
+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 is a
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 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
On Thu, Jun 12, 2008 at 5:05 AM, sebb [EMAIL PROTECTED] wrote:
On 12/06/2008, James Carman [EMAIL PROTECTED] wrote:
On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
[EMAIL PROTECTED] wrote:
Do you mean that the removal of the enums would mean that we have to
change package names?
]
Sent: Friday, June 20, 2008 8:43 AM
To: Commons Developers List
Subject: Re: [lang] Java 5
On Thu, Jun 12, 2008 at 5:05 AM, sebb [EMAIL PROTECTED] wrote:
On 12/06/2008, James Carman [EMAIL PROTECTED] wrote:
On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
[EMAIL PROTECTED] wrote:
Do you
, June 20, 2008 8:43 AM
To: Commons Developers List
Subject: Re: [lang] Java 5
On Thu, Jun 12, 2008 at 5:05 AM, sebb [EMAIL PROTECTED] wrote:
On 12/06/2008, James Carman [EMAIL PROTECTED] wrote:
On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
[EMAIL PROTECTED] wrote:
Do you
-Original Message-
From: sebb [mailto:[EMAIL PROTECTED]
Sent: Friday, June 20, 2008 9:47 AM
To: Commons Developers List
Subject: Re: [lang] Java 5
On 20/06/2008, Gary Gregory [EMAIL PROTECTED] wrote:
Isn't using a new package name the safest thing to do?
What if: My application depends
On 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 write my
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:
Do you mean that the
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 12, 2008
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
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?
[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
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 just internal
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,
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
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.0 moving to
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
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 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
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
*
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
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 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 a
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
1.5.
Do
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
On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
[EMAIL PROTECTED] wrote:
Do you mean that the removal of the enums would mean that we have to
change package names?
Would class/interface removals necessitate a
package name change? I haven't really thought that through.
Perhaps not,
On 12/06/2008, James Carman [EMAIL PROTECTED] wrote:
On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
[EMAIL PROTECTED] wrote:
Do you mean that the removal of the enums would mean that we have to
change package names?
Would class/interface removals necessitate a
package name
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 have
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
[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 decisions
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
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 I was thinking
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
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,
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 source
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
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 PROTECTED]
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 line
of code changes?
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
+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
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,
46 matches
Mail list logo
