Java 11 vs 14 MethodHandle behavior change

[Simone Bordet]

Hi,

On Tue, Apr 28, 2020 at 7:34 PM Mandy Chung <mandy.chung at oracle.com> wrote:
> endPointClass is in unnamed module and so it's unconditionally exported.  The public lookup should be able to find public members from it.    One thing to double check if endPointClass is publicly accessible?

It is.

> Did you get any exception in 14?  Is it from findVirtual or from in?

>From findVirtual():

Exception in thread "main" java.lang.IllegalAccessException: no such
method: org.module1.MyEndPoint.onMessage(MyString)void/invokeVirtual
    at java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:971)
    at java.base/java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:1114)
    at java.base/java.lang.invoke.MethodHandles$Lookup.resolveOrFail(MethodHandles.java:2785)
    at java.base/java.lang.invoke.MethodHandles$Lookup.findVirtual(MethodHandles.java:1883)
    at org.module2.Main.main(Main.java:28)
Caused by: java.lang.LinkageError: loader constraint violation: when
resolving method 'void
org.module1.MyEndPoint.onMessage(org.module1.MyString)' the class
loader 'bootstrap' of the current class, java/lang/Object, and the
class loader java.net.URLClassLoader @7291c18f for the method's
defining class, org/module1/MyEndPoint, have different Class objects
for the type org/module1/MyString used in the signature
(java.lang.Object is in module java.base of loader 'bootstrap';
org.module1.MyEndPoint is in unnamed module of loader
java.net.URLClassLoader @7291c18f, parent loader 'app')
    at java.base/java.lang.invoke.MethodHandleNatives.resolve(Native Method)
    at java.base/java.lang.invoke.MemberName$Factory.resolve(MemberName.java:1084)
    at java.base/java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:1111)
    ... 3 more

> The current implementation already does that.
>
>         private Class<?> lookupClassOrNull() {
>             if (allowedModes == TRUSTED) {
>                 return null;
>             }
>             if (allowedModes == UNCONDITIONAL) {
>                 // use Object as the caller to pass to VM doing resolution
>                 return Object.class;
>             }
>             return lookupClass;
>         }
>
> What exactly have you changed?

if (allowedModes == UNCONDITIONAL) {
    return lookupClass;
}

> Yes, please file a JBS issue and I will look into it.   If the requested target class to be accessed through Lookup::in is exported, it should work because the set of classes that public lookups can access should not change.

https://bugs.openjdk.java.net/browse/JDK-8244090

Thanks!

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz