Hi Simone, On 4/28/20 5:42 AM, Simone Bordet wrote:

Hi,

in Jetty 10, we use method handles in the WebSocket implementation.

We need to scan WebSocket EndPoint application classes (MyEndPoint) for annotated methods whose signature may vary and may take application classes, for example `@OnMessage void onMessage(Session s, MyString m)` where @OnMessage and Session are JSR 356 classes and MyEndPoint and MyString are application classes.

It may be possible that the same web application is deployed twice, perhaps with different configurations.

Therefore we have: * class "Impl" is the Jetty implementation class that creates MethodHandle.Lookup, loaded by serverClassLoader and in a named JPMS module * class MyEndPoint and MyString are in webapp1's WEB-INF/classes, loaded by webClassLoader1 in an unnamed JPMS module * class MyEndPoint and MyString are also in webapp2's WEB-INF/classes, loaded by webClassLoader2 in another unnamed JPMS module

Class Impl does this: MethodHandles.publicLookup().in(endPointClass).findVirtual(...), where "endPointClass" is class MyEndPoint loaded by the web class loader (either webClassLoader1 or webClassLoader2).

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?

We must call .in() to separate the 2 web applications (failing to call .in() results in linkage errors).

Calling publicLookup().in() works in Java 11-13.

In Java 14, it does not work anymore. The reason seems to stem from the fixes for https://bugs.openjdk.java.net/browse/JDK-8173978.

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

In particular, in Java 14 publicLookup() returns a Lookup with mode=UNCONDITIONAL (but not PUBLIC? Is this intended?)

Yes this is intentional.  The new public lookup returned has endPointClass as the lookup class (which should not have behavioral change).  The access modes are summarized in the javadoc: https://download.java.net/java/early_access/jdk15/docs/api/java.base/java/la... However, there is no behavioral change in public lookup.  Any lookup object with UNCONDITIONAL access mode assume readability and also finds all public accessible members as in Java 9. See also CSR JDK-8226916.

and Lookup.lookupClassOrNull() returns Object.class rather than the class passed to .in() - like it was doing in Java 11.

We have debugged and manually changed the return value of lookupClassOrNull() from Object.class to the endPoint class, and it works again.

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?

We have written a simple reproducer and been able to workaround the issue (we need to test it better in Jetty to confirm that the workaround for the simple reproducer also works in Jetty) by changing the Lookup from: publicLookup().in() to: lookup().dropLookupMode(<all apart PUBLIC>).in() and it also works.

Note that we really want to have a Lookup object with the minimum set of "powers" to lookup public methods in public classes of the web application - otherwise the JPMS configuration becomes more complicated.

We do have a simple reproducer that works in Java 11 and fails in 14. I am a JDK author so I can open an issue about this.

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. thanks Mandy