Proposal: Improved Wildcard Syntax for Java

[Howard Lovatt]

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.



>>        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.
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. Typically you want Object - just use
Object, no generics. Same argument as deprecating F-bounds, less is
more.

[snip]



>    If you want a proposal formally considered, you must fill out a proposal
>    form:
>    http://openjdk.java.net/projects/coin/#proposal_form



Happy to do this if there is some support, not much point spending the
time if it is just going to be rejected outright. By some support I
don't mean a guarantee that it will make it into 7, but I do mean that
people who have a vote in this process (you, who else?) think it is
worth considering and within scope for coin.



>>        So I am proposing eventually removing something from the language
>>        (actually replacing) - is removing a feature a first on coin-dev?



 >   However, the proposal form explicitly disallows removing features "The
 >   proposal must not remove existing features of the language...".



That was more a flippant comment at the end of the email, I am
proposing deprecating features (warning issued) - not removing them.

Cheers,

Howard.