Proposal: Improved Wildcard Syntax for Java (original) (raw)

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(). > 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>, 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 T max(Collection) (note Comparable would not be parameterised with the new syntax since you would almost always want Comparable). > 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/#proposalform 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