Lloyd L Chambers wrote:
> The way most methods are defined, it is possible to write code that
> doesn't require casts. The alternative requires casts for every
> call. In some cases, compatibility prevented use of improved method
> signatures including a "Class<T>: parameter.
>
> Using JNDIResource as a generic example, one can write the following:
>
> Set<JNDIResource> s = server.getResourceSet();
> TypeCast.checkSet( s, JNDIResource.class ); // optional, throws
> ClassCastException if elements are not all JNDIResource
> for( JNDIResource jndi : s ) {
> }
I guess the part that I don't understand is why a developer can assume
that this server only has JNDIResources (as opposed to, say,
FooBarResource?) Is that somehow implied by the type of the "server"
variable? If so, maybe what you wanted was co-variant return type?
Because if it's incorrect for me to assume that the set is really
actually Set<JNDIResource>s, then your cast elimination just ends up
masking the problem, because that cast should have made a programmer
think about "am I really always getting JNDIResource here?"
> I completely agree that getResourceSet( Class<T> type) is far better,
> but that would have been an incompatible change (which we wished to
> avoid), or an additional method. And getContaineeMap() already
> provides such functionality, though for compatibility reasons the
> type passed is String and not Class<T>.
Yeah, compatibility always bites us.
>> <T1 extends Serializable,T2 extends Serializable>
>> void startDeploy(Object deployID,
>> Map<String,T1> source,
>> Map<String,T2> plan,
>> Map<String,String> options)
>>
>> ... which should have been just:
>>
>> void startDeploy(Object deployID,
>> Map<String,? extends Serializable> source,
>> Map<String,? extends Serializable> plan,
>> Map<String,String> options)
>>
>
> I believe you are correct that the "? extends Serializable" choice
> would be preferable in this case. The T1/T2 construct enforces
> uniformity of type (though plain 'Serializable' would suffice also).
To the best of my knowledge, those two type signatures are identical. If
you are not convinced, I've heard that Effective Java reloaded explains
this better.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com