I recently tried to run an existing application under tomcat 9 with the Graal VM in JVM Runtime Mode, that means not as an Native exceutable, see https://www.graalvm.org/22.2/docs/introduction/#runtime-modes ).

I have a class similar like

public class MyBean {
  public String getText(Locale locale) { ... }
  public String getText() { ... }
}

When I use an EL expression like ${pageScope.mybean.text} it fails (returns null/an empty string) under certain conditions.

I think the problem is the following:

a) the JasperELResolver uses an GraalBeanELResolver when it thinks it runs under graal (see https://github.com/apache/tomcat/blob/main/java/org/apache/jasper/el/JasperELResolver.java#L72 ), I'm not sure if the GraalBeanELResolver would be really needed under Graal VM in JVM Runtime mode as this one should support reflection. But at the moment the JasperELResolver/JspRuntimeLibrary.GRAAL is configured to to so. 

b) the GraalBeanELResolver tries to find the getter of my property, see https://github.com/apache/tomcat/blob/79173cfbcaf6e82972cce98fbdc619e227037ab8/java/org/apache/jasper/el/JasperELResolver.java#L243 , to do so it simply iterates over all methods and tries to find "getText", it simply uses the first one. In my example above it depends on the order of beanClass.getMethods() if this will succeed at the end.

I think the GraalBeanELResolver should use the same logic as the default BeanELResolver which uses the java.beans.PropertyDescriptor.getReadMethod, this means to:
  - only search for getters without arguments
  - also honor the special "is" logic for boolean arguments

I only checked the code for reading (getValue) at the moment, but I guess also the setValue might have similar issues.

You might say that the above class MyBean is a bad architecture, but nevertheless with Graal VM the application behaves different than with standard JDK.

Above I wrote that the code fails in my case under "certain conditions". The exact difference was that it only failed when I had an "serletContext.setAttribute(ELInterpreterFactory.EL_INTERPRETER_CLASS_NAME, someCustomElInterpreter);"
in place. Nevertheless, this custom el interpreter did not interprete this special el expression on its own but used JspUtil.interpreterCall (which usees the default mechanism). But while debugging I saw that the main difference was the order of beanClass.getMethods() inside GraalBeanELResolver. I don't know how this order is determined. But in my optinion the GraalBeanELResolver should not rely on any specific order as the javadoc of getMethods says: "The elements in the returned array are not sorted and are not in any particular order."