Proposal: Improved Wildcard Syntax for Java

[Joseph D. Darcy]

Howard Lovatt wrote:
> Hi Joe,
>
> Thanks for the response, answers in text.
>
> 2009/3/18 Joseph D. Darcy <Joe.Darcy at sun.com> wrote:
>
> [snip]
>
>
>
>   
>>>        1. Deprecate raw declarations, new ArrayList() becomes a deprecated
>>>        warning - you need to say new ArrayList<Object>().
>>>       
>
>
>
>  >   That could be a fine lint option.  You could also write an annotation
>  >   processor that used the javac tree API to generated such warnings/errors
>  >   today.
>
>
>
> Yes you could - but I think it would be better in the language so that
> every implementation gets this useful behaviour.
>   

Language changes are not a quick way to enact change.  It is certainly 
possible that all implementations of interest can get a desirable 
feature without a language change and that such universal changes are 
usable sooner than a language change can be made officially available.  
All Java SE 6 compiler implementations are required to support 
annotation processing and each that I'm aware of has a tree API to 
provide additional information; therefore, additional checks that can 
easily be written as annotation processors are much better implemented 
and promulgated as annotation processors.

>>>        2a. Deprecate self references, you get a deprecated warning for class
>>>        Type<T extends Type<T>>, you wouldn't use generics in this case.
>>>       
>
>
>
>   
>>    F-bounds are part of Java's generics.
>>     
>
>
>
> Yes. But I am suggesting that we deprecate it because no one likes it.
>   

Simply because a feature is complicated or disliked doesn't imply it 
isn't technically desirable or necessary!

> The complication and confusion that it brings outweighs its benefit.
> Less is more.
>
> [snip]
>
>
>
>   
>>>        3. Deprecate the ability to specify multiple bounds, e.g. instead of
>>>        static <T extends Object & Comparable<? super T>> T max(Collection<?
>>>        extends T>) you write static <Comparable T> T max(Collection<T>) (note
>>>        Comparable would not be parameterised with the new syntax since you
>>>        would almost always want Comparable<Object>).
>>>       
>
>
>
>  >   There are reasons why multiple bounds are supported.
>
>
>
> Yes. Again not worth the trouble - don't use generics in these
> backward compatibility cases. 

The multiple bounds and the trick of putting Object as the first bound 
to maintain the desired erasure were added in JDK 5 to solve actual 
problems; see Gilad's "Generics in the Java Programming Language."
http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf

-Joe