LinkageError in IdentityStore.validate()

[hwellmann]

The use of MethodHandles in IdentityStore.validate() may lead to linkage errors.

This issue may occur in

MethodHandles.lookup()
    .bind(this, "validate", methodType(CredentialValidationResult.class, credential.getClass()))

when redeploying a web application.

In this case, methodType() may return a stale reference caused by the internal use of weak references which may still hang around if the classloader of the original deployment has not yet been garbage collected.

I ran into this problem when executing an Arquillian test suite on a remote server, where every test class gives rise to a new deployment. Observed on Java 8 as well as Java 11.

See https://github.com/hwellmann/method-type-leak for a self-contained test case.

Possible workaround:

Override IdentityStore.validate(Credential) in your custom class and downcast the Credentialargument to the concrete type.

[arjantijms]

You're right, this is indeed a potential issue and the workaround is valid as you describe.

Maybe it's possible to (hint) force garbage collect the class loader. Not sure though. This issue could definitely need some help.

[hwellmann]

Well, I'm afraid I don't understand enogh about method handles - the stale reference problem definitely is an issue at that level, and I don't know if that is by design or rather a bug (in the JDK, not in the Security API).

I'm not even sure that calling System.gc() guarantees that all weak references will be invalidated.

Possible approaches:

1. Call System.gc() in IdentityStore.validate() before calling methodType(). (Ugly and overkill.)
2. Wrap the MethodHandles stuff in a try-catch-block, catch IllegalAccessException, call System.gc() in the catch block and try again. (Still ugly.)
3. Use reflection instead of method handles, optionally caching the result of the method lookup.
4. Create an observer method for @Destroyed(ApplicationScoped.class) in the Security API implementation, and call System.gc() there, or invalidate the cache of option 3.

[keilw]

@arjantijms As this looks like a bug or problem it may be due for the Jakarta EE 8 branch. What are the planned versions of Jakarta Security that should contribute to the next Jakarta EE releases? I closed a JCP Milestone, the next one is nicknamed 1.1, is that still correct?