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

Joseph D. Darcy Joe.Darcy at Sun.COM
Tue Mar 17 13:34:47 PDT 2009

Howard Lovatt wrote:

Neal Gafter has proposed replacing the current wildcard syntax with in and out instead of extends and super; an alternative to the current extends/super and Neal's proposal would be to deprecate the current wildcards and to change to the behaviour to that of arrays (covariant only). In particular to change the wildcard syntax to SomeClass for variables, arguments, or fields, class AClass for classes, and for methods where T is compulsory when declaring classes or methods but not used when declaring variables etc. (i.e. exactly like method arguments). This new syntax is similar in behaviour to the current syntax SomeClass (the difference is that the new does not issue a warning for covariant assignment).

This proposal deprecates the concepts of SomeClass, SomeClass<?>, and SomeClass in the current syntax. Generics are made covariant so that List lo = new ArrayList() is OK and does not issue a warning (like arrays). If "lo" form the previous example has an object added to it, lo.add( new Object() ), then if this produces an error or not is dependant on the class in question (in the case or ArrayList it wouldn't). See http://www.artima.com/weblogs/viewpost.jsp?thread=222021 for more detail. At the same time I propose cleaning up other pain points with generics, in particular:

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.

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.

2b. It follows that <Type T> is an error in the new syntax, see next point for how you would do this.

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.

4. Allow arrays of parameterised types, List[] lsa = new ArrayList[10] is OK (you may get a runtime exception though if you misuse the feature).

Arrays and generics don't play well together; ignoring the impedance mismatch doesn't make the problem go away.

Examples of use of proposed new syntax are:

boolean isAnnotationPresent( Class annotationClass ); // was: boolean isAnnotationPresent( Class<? extends Annotation> annotationClass ); static createList( Collection coll ); // was: static createList( Collection<? extends Number> coll ); static void sort( List list ); // was: static <T_ _extends Comparable<? super T>> void sort( List list ); static Enum valueOf( Class enum, String name ); // was: static <T extends Enum> T valueOf( Class enum, String name ); The disadvantage of this proposal is that you can now get the equivalent of ArrayStoreExceptions, the reason that this is acceptable is that ArrayStoreExceptions are rare (I have never had one). For compatibility the existing syntax would still be allowed, but would issue a deprecated warning. The reason that I am proposing deprecating wildcards is that they are not worth the trouble (they have a poor cost/benifit ratio - less is more). I know the language pedants will hate this proposal, but I think the vast majority of Java users would welcome this change. This proposal has some overlap with the proposal to infer generic types in that they both concern generic declarations, but are otherwise orthogonal. The collections library, in particular methods like sort (see above) and interfaces like Comparable, and enum class would need updating to the new syntax and this new library would have to be supplied as a module so that old code could use the old library (nt 100% compatible).

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

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...".

-Joe

More information about the coin-dev mailing list