diamond operator and non-denotable types

Neal Gafter neal at gafter.com
Fri Apr 9 11:30:36 PDT 2010


How are these cases handed with static factories?  Why should it be handled
differently between static factories and constructors?  It seems that the
diamond operator should be capable of inferring any type arguments a static
factory could infer. Is there any reason for the diamond operator to be less

The exceptions are due to restrictions on construction.  "new ArrayList<?
extends Number>()" isn't legal, therefore "new ArrayList<>()" should not be
capable of inferring "? extends Number" for the type argument.

On Fri, Apr 9, 2010 at 10:14 AM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Despite attribution does not have problems with non-denotable types in
> instance creation expressions, there are circumstances in which such
> types cause problems in code generation --- this happens e.g. if a
> non-denotable type is inferred in an anonymous class creation
> expression; in this case the compiler will try to emit a classfile
> Signature attribute for a non-denotable type, which is not allowed.

That suggests that the restriction should be applied only to anonymous class
creation expressions.

Moreover non-denotable types doesn't seem to comply with the set of
> acceptable types in an instance creation expression (see JLS 15.9);
> despite there's no explicit statement in the JLS forbidding e.g. an
> intersection type as part of an instance creation expression, it seems
> sensible to statically forbid these occurrence, as the semantics of such
>  types is not crystal clear --- these types are introduced as
> compile-time artifacts in order to enhance the applicability of compiler
> checks, but it is not clear what their behavior should look like.

All generics are compile-time artifacts in order to enhance the
applicability of compiler checks.  Intersection types are specified,
representable in the class file, and erased at runtime too.  Where's the

> The most straightforward solution (see above) is to issue an error when
> a non-denotable type is returned as result of the diamond inference
> scheme. In other words, I propose to change the current spec draft to
> include a statement like:
> "If the diamond algorithm infers a non-denotable type, an error must be
> issued by the compiler".

"It is an error if the inferred class type parameters are not denotable and
a class body is present."

This requires a formal definition of "denotable".  Because it should not
include wildcards, which can be denoted in source, denotable is probably not
the right word.


More information about the coin-dev mailing list