Diamond operator and anonymous classes

[Dan Smith]

On Jun 25, 2011, at 12:07 AM, Derek Foster wrote:

> Hi, Dan.
> 
> Thanks for your reply. This is without a doubt the most informative writing I have seen on this subject.
> 
>> The fundamental problem is that inference in this case is more than just
>> inference of type arguments for a constructor call -- these are type
>> arguments for an 'extends' clause, which impacts inheritance/overloading
>> and the generated class file.
> 
> I can see how it would affect inheritance/overloading, but I must confess I don't understand how it would affect the generated class file. It seems to me that erasure would eliminate the impact of the generic parameters on the class file. What am I missing here? In any case, it seems to me that since generic resolution and diamondification is done at compile time, that the class file for a diamond operator should end up being the same as for the equivalent non-diamond declaration. Could you please clarify this?
> 
> I am a bit unclear on how non-denotable types raise more of an issue for anonymous types in the context of the diamond operator than they already do without the diamond operator in declarations such as the following:
> 
> 	class Q<R> {Q(Class<R> r) {}}
> 	<T extends java.util.Date & Closeable> Q<T> getAnon(Class<T> type) {
> 		final Q<T> q = new Q<T>(type) {
> 		};
> 		return q;
> 	}
> 
> which seems to be legal Java code as far as I can tell. (At least, Eclipse doesn't complain.) If I were to use "new Q<>()" in the above instead of "new Q<T>()", shouldn't the generated class file be the same?

See section 4.4.4, here:

<http://java.sun.com/docs/books/jvms/second_edition/ClassFileFormat-Java5.pdf>

The concern over "denotable types" is with types that cannot be denoted with a FieldTypeSignature.  This includes intersection types and capture variables (standard type variables, as in your example, _are_ denotable).

Example:

// Assume LiteralList has a constructor like Arrays.asList
// Inferred type argument is Number & Comparable<? extends ...>
method(new LiteralList<>(1, 2.0) { ... });

Of course this is atypical, and one could envision carving out such special cases as unsupported, rather than throwing out all anonymous classes.  But see my previous comments about why we felt that "no anonymous classes" was the right place to draw the line for now.

—Dan