Openjdk openJ9 vs hotspot reflection difference using ZKOSS

Question

I'm currently using a web application using the ZK ( https://www.zkoss.org/ ) framework successfully using a HotSpot JVM ( https://adoptopenjdk.net/?variant=openjdk11&jvmVariant=hotspot ). Using this JVM, ZK can reflectively access my objects (beans) using its EL package. When I try running it with another standard-JVM (openj9 from https://adoptopenjdk.net/?variant=openjdk11&jvmVariant=openj9 ), reflectively accessing attributions of certain object lead to exceptions (see end of this message). I'd like to use this JVM as its memory footprint is smaller than hotspot for my application.

ZK version in use is 8.6.2 (bind/common)

Is there any reason why a different JVM would lead to different results? If so, how should I troubleshoot it?

In this specific case, ZK uses a forked version of Apache Common EL, which is a discontinued project.(2003). The exception I get is listed below. Here, the framework has failed to access the object (application-level object, not java.lang.Long) in question, and is calling a method that does not exist on Long (but exists in application object).

org.zkoss.zel.PropertyNotFoundException: Property 'visible' not found on type java.lang.Long
at org.zkoss.zel.BeanELResolver$BeanProperties.get(BeanELResolver.java:424) ~[zel_8.6.2.jar:8.6.2]
at org.zkoss.zel.BeanELResolver$BeanProperties.access$300(BeanELResolver.java:375) ~[zel_8.6.2.jar:8.6.2]
at org.zkoss.zel.BeanELResolver.property(BeanELResolver.java:547) ~[zel_8.6.2.jar:8.6.2]
at org.zkoss.zel.BeanELResolver.getValue(BeanELResolver.java:98) ~[zel_8.6.2.jar:8.6.2]
at org.zkoss.zel.CompositeELResolver.getValue(CompositeELResolver.java:66) ~[zel_8.6.2.jar:8.6.2]
at org.zkoss.zel.CompositeELResolver.getValue(CompositeELResolver.java:66) ~[zel_8.6.2.jar:8.6.2]
at org.zkoss.zel.CompositeELResolver.getValue(CompositeELResolver.java:66) ~[zel_8.6.2.jar:8.6.2]
at org.zkoss.xel.zel.XelELResolver.getValue(XelELResolver.java:99) ~[zcommon_8.6.2.jar:8.6.2]
at org.zkoss.bind.xel.zel.BindELResolver.getValue(BindELResolver.java:123) ~[zkbind_8.6.2.jar:8.6.2]
at org.zkoss.zel.impl.parser.AstValue.getValue(AstValue.java:188) ~[zel_8.6.2.jar:8.6.2]
at org.zkoss.zel.impl.ValueExpressionImpl.getValue(ValueExpressionImpl.java:184) ~[zel_8.6.2.jar:8.6.2]
at org.zkoss.zkmax.bind.impl.ValueExpressionImplEx.getValue(ValueExpressionImplEx.java:52) ~[zkmax_8.6.2.jar:8.6.2]
at org.zkoss.xel.zel.ELXelExpression.evaluate(ELXelExpression.java:41) ~[zcommon_8.6.2.jar:8.6.2]
at org.zkoss.zkmax.bind.impl.BindEvaluatorXImplEx$LazyBindXelExpression.evaluate(BindEvaluatorXImplEx.java:124) ~[zkmax_8.6.2.jar:8.6.2]
at org.zkoss.bind.impl.BindEvaluatorXImpl.getValue(BindEvaluatorXImpl.java:46) ~[zkbind_8.6.2.jar:8.6.2]
at org.zkoss.bind.impl.LoadPropertyBindingImpl.load(LoadPropertyBindingImpl.java:58) ~[zkbind_8.6.2.jar:8.6.2]
at org.zkoss.bind.impl.PropertyBindingHandler.doLoadBinding(PropertyBindingHandler.java:140) ~[zkbind_8.6.2.jar:8.6.2]
at org.zkoss.bind.impl.PropertyBindingHandler.doLoad(PropertyBindingHandler.java:341) ~[zkbind_8.6.2.jar:8.6.2]
at org.zkoss.bind.impl.BinderImpl.loadComponentProperties0(BinderImpl.java:2491) ~[zkbind_8.6.2.jar:8.6.2]
at org.zkoss.bind.impl.BinderImpl.loadComponent0(BinderImpl.java:2458) ~[zkbind_8.6.2.jar:8.6.2]
at org.zkoss.bind.impl.BinderImpl.loadComponent(BinderImpl.java:2393) ~[zkbind_8.6.2.jar:8.6.2]
at org.zkoss.bind.tracker.impl.BindUiLifeCycle.reInitBinder0(BindUiLifeCycle.java:170) ~[zkbind_8.6.2.jar:8.6.2]
at org.zkoss.bind.tracker.impl.BindUiLifeCycle.reInitBinder(BindUiLifeCycle.java:109) ~[zkbind_8.6.2.jar:8.6.2]
at org.zkoss.bind.tracker.impl.BindUiLifeCycle.access$100(BindUiLifeCycle.java:55) ~[zkbind_8.6.2.jar:8.6.2]
at org.zkoss.bind.tracker.impl.BindUiLifeCycle$2.onEvent(BindUiLifeCycle.java:100) ~[zkbind_8.6.2.jar:8.6.2]
at org.zkoss.zk.ui.AbstractComponent.onEvent(AbstractComponent.java:3179) ~[zk_8.6.2.jar:8.6.2]
at org.zkoss.zk.ui.AbstractComponent.service(AbstractComponent.java:3127) ~[zk_8.6.2.jar:8.6.2]
at org.zkoss.zk.ui.AbstractComponent.service(AbstractComponent.java:3091) ~[zk_8.6.2.jar:8.6.2]
at org.zkoss.zk.ui.impl.EventProcessor.process(EventProcessor.java:138) ~[zk_8.6.2.jar:8.6.2]
at org.zkoss.zk.ui.impl.UiEngineImpl.processEvent(UiEngineImpl.java:1845) ~[zk_8.6.2.jar:8.6.2]
at org.zkoss.zk.ui.impl.UiEngineImpl.process(UiEngineImpl.java:1617) ~[zk_8.6.2.jar:8.6.2]
at org.zkoss.zk.ui.impl.UiEngineImpl.execUpdate(UiEngineImpl.java:1320) ~[zk_8.6.2.jar:8.6.2]
at org.zkoss.zk.au.http.DHtmlUpdateServlet.process(DHtmlUpdateServlet.java:611) ~[zk_8.6.2.jar:8.6.2]
at com.castortech.iris.ba.webviewer.internal.ZkUpdateServlet.process(ZkUpdateServlet.java:62) ~[com.castortech.iris.ba.webviewer/:na]
at org.zkoss.zk.au.http.DHtmlUpdateServlet.doGet(DHtmlUpdateServlet.java:487) ~[zk_8.6.2.jar:8.6.2]
at org.zkoss.zk.au.http.DHtmlUpdateServlet.doPost(DHtmlUpdateServlet.java:495) ~[zk_8.6.2.jar:8.6.2]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) ~[javax.servlet_3.1.0.v201410161800.jar:3.1.0]

Answer 1

obviously something went wrong there...

In order to troubleshoot this, a reproducing example would be most helpful. Eg a simple zul file showing the an EL expression causing this error in combination with a simplified ViewModel and required Bean class(es). This will greatly improve the chances of someone picking up the issue.

Ideally provide a runnable example on zkfiddle.org (even if it doesn't show the error on the JVM used there - it will help to test the exact scenario using the adoptJDK version you mention on a local machine).

Or if you can't share any code in public, zkoss offers dedicated customer support .

Answer 2

I don't know if you could solve it yet.But I've had pretty much the same error. Zk tried to get the property from the wrong object. I think I've also got a very similar stack, so maybe it's the same problem as you had. After a lot of wtf?! and way too long debugging I found out what the reason was. When two objects have the same hash value, ZK assumes during the set-binding process, that they are the same object. So especially when you use an own hashcode() implementation on your entities, the change is that that happens.