What is the motivation behind the descriptor visibility rules ?

[Remi Forax]

On 02/27/2013 06:41 PM, Srikanth S Adayapalam 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.
>
> Srikanth. 

I believe the problem is that for classical covariant override the 
compiler can generate a bridge, I always find that dubious but you can. 
Lambda proxies are generated at runtime, and at runtime you can easily 
trigger a runtime error because a class is not visible when by example 
you use reflection in order to generate the bytecode of the proxy.

BTW, this code doesn't work with Eclipse but compiles with javac:

package fizz;
class X {
}

package fizz;
public interface A {
   public X m();
}

package fizz;
public class Y extends X {
}

package buzz;
import fizz.A;
import fizz.Y;
public class Main {
   static class B implements A {
     public Y m() {
       System.out.println("B::m");
       return null;
     }
   }

   public static void main(String[] args) {
     A a = new B();
     a.m();
   }
}

cheers,
Rémi