In the valhalla nestmates branch, lambda metafactory has undergone some evolution and the lambda proxy class is no longer created with `Unsafe::defineAnonymousClass` but rather with `Lookup::defineHiddenClass`.

The lambda proxy class is created as a hidden nestmate of the target class and it follows the proper access control checks.

The older Unsafe::defineAnonymousClass mechanism was somewhat lenient/permissive in access control checks and was granting access to a protected member in its super class in a different package of the host class. The new Lookup::defineHiddenClass conforms to the proper access control checks. As a result, the lambda proxy class is a nestmate of the target class and it gets IAE when invoking super::protectedMember where its super class is in a different package from nestmate class.

This problem was addressed in the nestmates branch by JDK-8227415 which basically converts the method reference into lambda expression. 

(Javac's needsConversionToLambda() infrastructure is used fold method references into lambdas to workaround various quirks/limitations/defects in the lambda metafactory/bootstrap mechanism. It just chooses an alternate code generation scheme that does not triggers those quirks/limitations/defects.)

In the new code generation scheme where a method reference is converted into a lambda expression, there is no violation of any access control rule, since lambda proxy invokes a "bridge" method that is in the same package as the lambda proxy class.

There is an incompatibility concern when LambdaMetaFactory migrates to use hidden classes due to the missing access bridge to access the protected method reference declared in super class in different package.

For classes compiled with existing releases, IllegalAccessError will be thrown for the scenario discussed when the application is run under a VM that uses Lookup::defineHiddenClass

Hidden classes are expected in a release post 14, it would be prudent on the part of javac to eagerly alter the code generation for the concerned scenario, so as allow smoother migration of code to a hidden classes enabled VM