"java.lang.AssertionError: java.lang.NoSuchFieldException: target" on s390x with Corda

[rickcrook]

Java -version output

Output from java -version.

openjdk version "1.8.0_275"
OpenJDK Runtime Environment (build 1.8.0_275-b01)
Eclipse OpenJ9 VM (build openj9-0.23.0, JRE 1.8.0 Linux s390x-64-Bit Compressed References 20201110_824 (JIT enabled, AOT enabled)
OpenJ9   - 0394ef754
OMR      - 582366ae5
JCL      - b52d2ff7ee based on jdk8u275-b01)

running in adoptopenjdk/openjdk8-openj9:jdk8u275-b01_openj9-0.23.0
on x390x/LinuxOne

Summary of problem

Exception raised java.lang.AssertionError: java.lang.NoSuchFieldException: target while running java -jar corda.jar

A quick scan of the internet shows this has been seen before puniverse/quasar#321 and been added to corda/corda#5139.
Switching to Hotspot (as per one suggestion) yields a deeper issue see #11956 & adoptium/adoptium-support#257

  / ____/     _________/ /___ _
 / /     __  / ___/ __  / __ `/         If at first you don't succeed, 
/ /___  /_/ / /  / /_/ / /_/ /          then we have something in common!
\____/     /_/   \__,_/\__,_/

--- Corda Open Source 4.6 (85e387e) -------------------------------------------------------------

Diagnostic files

app.log

[joransiu]

From the app.log:

Caused by: java.lang.NoSuchFieldException: target
	at java.lang.Class.getDeclaredFieldImpl(Native Method) ~[?:1.8.0_275]
	at java.lang.Class.getDeclaredField(Class.java:825) ~[?:1.8.0_275]
	at co.paralleluniverse.common.reflection.GetDeclaredField.run(GetDeclaredField.java:17) ~[quasar-core-0.7.13_r3.jar:0.7.13_r3]
	at co.paralleluniverse.common.reflection.GetDeclaredField.run(GetDeclaredField.java:6) ~[quasar-core-0.7.13_r3.jar:0.7.13_r3]
	at java.security.AccessController.doPrivileged(AccessController.java:734) ~[?:1.8.0_275]
	at co.paralleluniverse.concurrent.util.ThreadAccess.<clinit>(ThreadAccess.java:53) ~[quasar-core-0.7.13_r3.jar:0.7.13_r3]

I couldn't find the 0.7.13 level of quasar. From 0.7.10, it should be related to this line: https://github.com/puniverse/quasar/blob/v0.7.10/quasar-core/src/main/java/co/paralleluniverse/concurrent/util/ThreadAccess.java#L48

Given the getter/setters for this target field are Runnable type, the corresponding private field within our Thread implementation would be runnable (https://github.com/eclipse/openj9/blob/master/jcl/src/java.base/share/classes/java/lang/Thread.java#L96).

As private fields are usually not externalized, arguably, the issue lies in quasar code making an implementation-dependent assumption. FWIW, the other three fields that are queried do exist in our Thread implementation.

@rickcrook : Any chance you can pull the source of your quasar library, and update the field name from target to runnable (alternatively, add another query for runnable if target is not found) to see if you get further?

[rickcrook]

@joransiu Thank you. It would appear @pron already made the suggested change to the R3 fork of the quasar code in Nov 2018 which made it into release-0.8.2_r3 but not v0.7.13_r3 (release 30 Jul 2020).
corda/quasar@25031be#diff-e236b21e9830dc9153172ac25b37aa2df6cc81e9ec201105a26c95bc50fbe7f7

I'll follow up with Corda team and raise the issue on https://github.com/corda/quasar/