Proposal: Improved Wildcard Syntax for Java
Jonathan Gibbons
Jonathan.Gibbons at Sun.COM
Tue Mar 17 18:31:34 PDT 2009
With respect to (1), see -Xlint:raw.
-- Jon
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.
>
>
>
>
>>> 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.
>
>
More information about the coin-dev
mailing list