ELResolvers with jdk17 can cause InaccessibleObjectException

Environment (Required on creation):

C7.17 and higher, any distro with jdk17.

Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket):

We resolve expressions via reflection. Before we invoke the expression's method we check if it's accessible via reflection and call the setAccessible on the method when needed. From Java 9 this method throws two exceptions (SecurityException & InaccessibleObjectException).
Our logic is not handling the second exception. With previous java versions it didn't cause issues but Java 17 introduced very strong internal encapsulation rules.
So under Java 17 starting a process can fail completely due to the second InaccessibleObjectException exception.

Steps to reproduce (Required on creation):

Have a bpmn process with conditional expression defined, for instance: ${actionList.contains("MANUELL")}. Start the process with the variables. In the variables add the actionList list initialised by the java.util.List.of() method.

The process would fail with InaccessibleObjectException.

Arrays.asList() would probably trigger the same exception (and many other classes, too).

Observed Behavior (Required on creation):

The process fails with InaccessibleObjectException.

Expected behavior (Required on creation):

The process should complete successfully.

Root Cause (Required on prioritization):

Expressions in the process are evaluated using reflection. When we encounter a method that's not accessible by default, we try to make it accessible. The above mentioned contains method cannot be made accessible in jdk17. So our attempt fails with an InaccessibleObjectException exception which is not handled properly in the BeanELResolver.
(org.camunda.bpm.engine.impl.javax.el.BeanELResolver@97)

Solution Ideas (Optional):

Hints (optional):

We need to handle both exceptions whenever we call method.setAccessible(). However we can't use classes that are not available in Java 8 as we still build our codebase with that.