What is the motivation behind the descriptor visibility rules ?

[Dan Smith]

On Feb 27, 2013, at 10:41 AM, Srikanth S Adayapalam <srikanth_sankaran at in.ibm.com> wrote:

> Hello ! 
> 
>         15.27.3 and 15.28.1 state: 
> 
> It is a compile-time error if any class or interface mentioned by either T'  
> or the descriptor of T' is not accessible from the class in which the lambda 
> expression appears. 
> 
>         I would like to understand the motivation behind these rules. These 
> are more restrictive than a normal method overriding (lambda case) scenario: 
> (under covariance return could be a visible subtype of an inaccessible declared 
> return type in super method, thrown exceptions don't have be visible as long 
> as the subtype implementation does not want to throw them) 
> 
> This rule is also more restrictive than a method invocation scenario (method/constructor 
> reference case) where even the parameter types need not be visible. 
> 
> I don't have a real case where this is hurting, but with jigsaw knocking at the doors, 
> I wonder if contours could emerge in different ways and there could be strange bed 
> fellows. 

Lambas and method references _both_ implicitly override the descriptor, and always match it exactly.  It's morally equivalent to:

class FuncImpl<S,T> implements Func<S,T> {
  public Return method(Param1 x, Param2 y) throws Throws {
    lambda body or referenced method invocation
  }
}
new FuncImpl<Targ1, Targ2>();

If this were in the source, all the types mentioned above would need to be accessible.

Now, it's possible that some implementations won't actually need to mention all of those types, but we don't want to require them to have to find clever workarounds (like introducing a covariant override).

—Dan