On 4/29/20 2:07 AM, Simone Bordet wrote:
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
Thanks for the reproducer. `publicLookup().in(endPointClass1)` in JDK 13 produces a Lookup object on endPointClass1 with PUBLIC access only. UNCONDITIONAL bit was lost. The resulting Lookup can access classes unconditionally exported from module M that the module of endPointClass1 can read. The resulting Lookup is no longer a public lookup, i.e. the lookup context is the lookup class (i.e. endPointClass1) and the lookup mode (i.e. PUBLIC). `publicLookup().in(endPointClass1)` in JDK 14 produces a Lookup object on endPointClass1 with UNCONDITIONAL bit due to the spec change for JDK-8173978. The resulting Lookup remains to be a public lookup which can access any unconditionally exported classes from any module. Although the lookup class of the teleported public Lookup is endPointClass1, it should not affect the lookup context. Unfortunately, the workaround for JDK-8228671 causes this bug. The reproducer shows that the new public Lookup uses Object as the lookup clsas that violates the loader constraint. lookup1 finds "org.module1.MyEndPoint" loaded by CL1 and it adds a loader constraint with the boot loader (rather than CL1) due to the workaround fixed by JDK-8228671 that uses Object as the lookup class. When lookup2 finds "org.module1.MyEndPoint" loaded by CL2, the lookup fails with loader constraint violation.
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; }
This patch will hit the assertion that JDK-8228671 ran into. We need a long-term fix (perhaps to look into JDK-8173977)
Thanks. I will look into it. Mandy