Method/Constructor references.

[Srikanth S Adayapalam]

(1) 0.6.1, 15.28 says:

"It is a compile-time error if the ClassType of a constructor reference 
denotes a class that is an enum type or that is abstract. "

While JLS7 15.9 in addition says:

"It is a compile-time error if any of the type arguments used in a class 
instance
creation expression are wildcard type arguments (§4.5.1)."

So is the less restrictive version with constructor references intentional 
? I don't see anything in
the design/motivation section regarding this to determine if it is.

I would like to use one definition of what can be instantiated unless the 
relaxation is deliberate.

So, should the following program compile ? 

// ---
interface I {
  X<?> zoo(int x, String p);
}
public class X<T> {
        X(int x, String p) {}
        I i = X<? extends String>::new; // will compile
      X<?> x = new X<? extends String>(); // will not compile.
}

I don't see a type safety issue here since the parameterization would have 
pass bounds check, only a consistency issue.

(2) And since the production for ClassType (despite the name) cannot prune 
type variables and
annotation types, should these also be called out as error scenarios ? 

(3) Should the (obvious) point about primary evaluating to base type being 
a forbidden scenario
be mentioned ? 

(4) "The immediately enclosing instance of an inner class instance (15.9.2
) must be provided for a constructor reference by a lexically enclosing 
instance of this (8.1.3). "
Is this restrictive ? Can this be supplied at method invocation time or 
even via a primary from ? Implementable != useful and
I don't have an assessment as to how useful practically it would be 
though. Again this is a consistency issue: the call to
new Inner() can occur outside of the enclosing class in an entirely 
unrelated class as long as there an enclosing instance is
available and the types are visible.


Srikanth



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20130216/9a3d59e2/attachment.html