commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Kestle <stephen.kes...@orionhealth.com>
Subject Re: [collections] VOTE: Collections-java5 direction ; notifying collections
Date Tue, 13 Mar 2007 03:15:11 GMT
Bryce L Nordgren wrote:
> Stephen Kestle <stephen.kestle@orionhealth.com> wrote on 03/12/2007
> 07:05:21 PM:
>
>   
>> I'm unsure why people who use Java 5 only should pay a runtime penalty
>> when it isn't needed.  If this issue concerns you, use
>> java.utils.Collection.CheckedCollection.
>>     
>
> Being a C fanatic, I said the same thing about array bounds checking and
> garbage collection.  In for a penny in for a pound.  But at least in C I
> _knew_ I was responsible for ... well... everything.
>   
Granted - I guess it's also the problem of having to pass a class in 
instead of a type.  If there were a relatively easy way to support both, 
then that'd be cool.
> This may be an example of my point about illusory safety.  You write all
> your own code from scratch?  Or you use only libraries which have been
> generified?  
I only use generified libraries - or rather, only need collections 
utilities to be generified.  I haven't come across any libs that have 
caused me trouble (apart from servlet stuff).  Usually, the API is so 
simple it is well known what the return type will be, and so I wrap the 
API with something that does the generic casts and suppresses the 
warning.  I suppose I could do runtime checking too, but I've never had 
class cast exceptions from that before.  (I usually get them when 
chaining transformers and get the output types mixed up).
> You never pass a Java5 collection to a library written before
> generics?  To give an example close to home: you _never_ use the current
> commons-collections, in particular the "TransformedCollection" decorator?
>   
I use sf.collections, and never used the TransformedCollection, because 
I thought it was the same as TransformedMap which only transforms th
> Are you going to still produce binary releases which are compatible with
> 1.4, even though they won't be able to compile the new source releases?  Or
> are you going to use some sort of code stripper thingy which gets rid of
> generics for backwards source compatibility?  
No, not as far as the conversation is going. 
> Bear in mind that SDKs <=1.4
> inspired this library due to perceived shortcomings in the reference
> implementations of the collection framework interfaces.  It seems
> counterintuitive to make SDKs >= 1.5 the only platform on which this can
> compile.  But as long as the binaries stay backwards-compatible, that's OK.
>   
Why bother?  The current collections serve very well for <=1.4. The 
major pain is coming from 1.5 users having to suppress warnings all over 
the place if they want to use commons-collections. 
I understand that the binary break will limit the backwards 
compatibility, but if you're needing to develop for 1.4 and 1.5, use 1.4 
libs.  As far as I see, most people leap to Java 5 rather than tip toeing. 

Perhaps someone who cares enough about this could get a build working 
with retroweaver - I don't think there's any use of new API classes in 
collections, so that should work a treat.  But that still wouldn't be 
binary compatible.

Cheers

Stephen


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message