[lang] Java 5

classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[lang] Java 5

Matt Benson
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [lang] Java 5

Gary Gregory
+1 for Java 5 and using generics.

Gary

-----Original Message-----
From: Matt Benson [mailto:[hidden email]]
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: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Java 5

James Carman
In reply to this post by Matt Benson
On Wed, Jun 11, 2008 at 4:10 PM, Matt Benson <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Java 5

Ralph Goers
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Java 5

Aaron Zeckoski
In reply to this post by Matt Benson
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



--
Aaron Zeckoski ([hidden email])
Senior Research Engineer - CARET - Cambridge University
[http://bugs.sakaiproject.org/confluence/display/~aaronz/]
Sakai Fellow - [http://aaronz-sakai.blogspot.com/]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Java 5

simon.kitching@chello.at
In reply to this post by James Carman
James Carman schrieb:

> On Wed, Jun 11, 2008 at 4:10 PM, Matt Benson <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Java 5

Tom Schindl-3
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

[hidden email] schrieb:

> James Carman schrieb:
>> On Wed, Jun 11, 2008 at 4:10 PM, Matt Benson <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Java 5

simon.kitching@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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Java 5

Tom Schindl-3
I think we should ask the felix people what can be solved with OSGi and
what can not.

Tom

[hidden email] 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: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Java 5

Mario Ivankovits
In reply to this post by simon.kitching@chello.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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Java 5

Niall Pemberton
In reply to this post by James Carman
On Thu, Jun 12, 2008 at 4:43 AM, James Carman
<[hidden email]> wrote:

> On Wed, Jun 11, 2008 at 4:10 PM, Matt Benson <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Java 5

James Carman
On Thu, Jun 12, 2008 at 7:11 AM, Niall Pemberton
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Java 5

James Carman
In reply to this post by Ralph Goers
On Thu, Jun 12, 2008 at 2:46 AM, Ralph Goers <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Java 5

Niall Pemberton
In reply to this post by James Carman
On Thu, Jun 12, 2008 at 12:19 PM, James Carman
<[hidden email]> wrote:

> On Thu, Jun 12, 2008 at 7:11 AM, Niall Pemberton
> <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Java 5

James Carman
In reply to this post by Niall Pemberton
On Thu, Jun 12, 2008 at 7:11 AM, Niall Pemberton
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Java 5

James Carman
In reply to this post by Niall Pemberton
On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Java 5

sebb-2-2
On 12/06/2008, James Carman <[hidden email]> wrote:

> On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton
>
> <[hidden email]> 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: [hidden email]
>  For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Java 5

James Carman
On Thu, Jun 12, 2008 at 8:05 AM, sebb <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [lang] Java 5

Jörg Schaible-2
In reply to this post by James Carman
[hidden email] wrote:

> On Thu, Jun 12, 2008 at 7:11 AM, Niall Pemberton
> <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Java 5

Emmanuel Bourg-3
In reply to this post by sebb-2-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

123