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

Howard Lovatt howard.lovatt at iee.org
Tue Mar 17 17:54:56 PDT 2009

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