Skip to content

LambdaFetchingSupport is broken for cross class loader method access after JDK >= 14 #3369

@jord1e

Description

@jord1e

Describe the bug
Whilst working on #2789 I found this bug.

Java changed the way MethodHandles.privateLookupIn behaves in JDK 14 (?):
A new Lookup::hasFullPrivilegeAccess method for testing full privilege access

This effectively breaks LambdaFetchingSupport.createGetter in cross class loader situations and always silently goes into the try (... ignore) {} and falls back to the original reflection:

Image of the debugger

To Reproduce
Run the LambdaFetchingSupportTest.'different class loaders induce certain behaviours' on a JDK 14+ (triggered for me on JDK 17)

How to fix

Jackson fixed this by (if I understand correctly) creating a dummy class in the same package as the 'hidden' class that has a static reference to the MethodHandle.Lookup instance, which can then be resolved using reflection:

https://github.com/FasterXML/jackson-modules-base/pull/162/files#diff-e2b60292366182a59ba6f53b823219367d18eb1de225ecaf783ea7c7f70b04b2R94

To fix this for GraphQL Java the GrantAccess.java would need to be edited a bit to give the "dummy" class a different name i.e, GraphQLJavaAccess, running this will create the necessary class bytes

Then the CrossLoaderAccess would be copied and the bytes would be modified with the correct class bytes that were generated.

Then the class would have to be "opened up" in LambdaFetchingSupport.getLookup (see CrossLoaderAccess.apply) after which it will work like normal again

Other
I am unsure of how many deployments this applies to, but considering that having GraphQL Java in one class loader and the target classes in another is not the craziest idea, it should probably be fixed. Especially considering the performance gains (#2985 )

It probably wasn't noticed because the tests have not been run JDK>11 because of Gradle toolchains: 091710c#diff-335d1791aad84b00e8762546a158726200525fa06a55b73d8284ff0fea4ac7deR186

#2789 would of course fix this by testing on newer releases

This was also implemented in OpenJ9: eclipse-openj9/openj9#8571
After JDK 17 some things might again be slightly different: https://bugs.openjdk.org/browse/JDK-8221255
Email chain from Jackson Blackbird to lib-core-devs: https://www.mail-archive.com/core-libs-dev@openjdk.java.net/msg83157.html

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions