Bryce L Nordgren wrote:
Stephen Kestle <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
