During type check of a method invocation Byteman searches for candidate methods which might match the call by recursively searching up the super and interface tree starting from the (potentially only lexically scoped) type currently associated with the method target. That search uses reflection to locate potentially matching methods. In certain unusual classloader configurations this can lead to a Linkage error being emitted by the JVM. The Linkage error is not observed in normal running even thought the class mismatch which gives rise to it still appears to apply. This suggests that the problem may not be to do with Byteman but may actually be to do with a disparity between how classes are resolved by the JVM under reflection operations and how they are resolved by Java classloading operations.

The reproducer is provided in the noted forum thread. It turns upon a class with the same name appearing in both the bootstrap classpath and in the scope of a module loader on which the target class's loader depends (it is a necessary condition for a Linkage error to be thrown that two different classes with the same name be encountered when resolving a class and/or the classes it depends on/references). The reproducer works when using the H2 database driver implementation of XAResource but the same problem also happens with the Postgres driver, apparently for the same reason.