I'm not 100% sure how it is intended with the mocking bridge fields that are stored in NegativeArraySizeException
or similar, but it doesn't work too nicely if you use JMockit from multiple classloaders.
To reproduce the error, just comment out the MockingBridge.setMockingBridgeFields();
line from my PR #309. Tests that use mocking bridge fields will fail thereafter, e. g. changeContextCLDuringReplay()
will fail with a NullPointerException
.
The problem here is, if you initialize JMockit on some class loader B where it was not initialized yet, the mocking bridge fields in NegativeArraySizeException
or similar are updated to the ones from that class loader B and the ones from class loaders (A) where JMockit was initialized before are lost at this place.
If you then use JMockit on the class loader A where it was initilized before B, the classes from A are used. But the transformed-in calls that use the mocking bridge fields in NegativeArraySizeException
or similar use the mocking bridges from class loader B which does not harmonize of course, as then various static fields etc. are not like expected, like e. g. mockit.internal.state.MockClasses#mockupClassesToMockupInstances
which misses the instances in the B version that are present in the A version.
I'd like to report this either as bug if JMockit should work fine with multiple classloaders, or as improvement request if this is expected behaviour.
Also if this is expected behaviour for now, please at least document it somewhere (I didn't find it mentioned) and maybe add some check that recognizes that the mocking bridge fields class loader does not match the other JMockit classes class loader and raise some meaningful error that explains that you can only use JMockit on one class loader at a time and if you switched to a new class loader that you cannot easily go back to the old one.
enhancement