Openj9: Mockito inlining appears to fail on J9/windows but work on J9/mac

[planetf1]

I tried building http://github.com/odpi/egeria using the JDK 8 192 J9 SDK from adoptopenjdk on Windows 10. A few of the tests use mockito inline mocking and failed (see log below)

I then tried using JDK 8 192 SDK from adoptopenjdk on MacOS Mojave and it all seemed to work just fine, as indeed does both the oracle jdk on windows, and openjdk/hotspot on windows.

So this looks like an issue with the Windows 10 JDK

I do not know if this is a build issue, or the code.

original discussion was at https://adoptopenjdk.slack.com/archives/C09NLQQAV/p1540215988000100

Error I hit was:

[INFO] Running org.odpi.openmetadata.accessservices.governanceengine.client.GovernanceEngineImplTest
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
[ERROR] Tests run: 26, Failures: 0, Errors: 26, Skipped: 0, Time elapsed: 2.352 s <<< FAILURE! - in org.odpi.openmetadata.accessservices.governanceengine.client.GovernanceEngineImplTest
[ERROR] testGetGovernedAssetComponentListBadConstructorEmpty  Time elapsed: 1.862 s  <<< ERROR!
org.mockito.exceptions.base.MockitoException:

Mockito cannot mock this class: class org.springframework.web.client.RestTemplate.

If you're not sure why you're getting this error, please report to the mailing list.


Java               : 1.8
JVM vendor name    : Eclipse OpenJ9
JVM vendor version : openj9-0.11.0
JVM name           : Eclipse OpenJ9 VM
JVM version        : 1.8.0_192-b12
JVM info           : JRE 1.8.0 Windows 10 amd64-64-Bit Compressed References 20181019_105 (JIT enabled, AOT enabled)
OpenJ9   - 090ff9dc
OMR      - ea548a66
JCL      - 51609250b5 based on jdk8u192-b12
OS name            : Windows 10
OS version         : 10.0


You are seeing this disclaimer because Mockito is configured to create inlined mocks.
You can learn about inline mocks and their limitations under item #39 of the Mockito class javadoc.

Underlying exception : org.mockito.exceptions.base.MockitoException: Could not modify all classes [class org.springframework.http.client.support.HttpAccessor, class org.springframework.web.client.RestTemplate, interface org.springframework.web.client.RestOperations, class org.springframework.http.client.support.InterceptingHttpAccessor, class java.lang.Object]
Caused by: org.mockito.exceptions.base.MockitoException: Could not modify all classes [class org.springframework.http.client.support.HttpAccessor, class org.springframework.web.client.RestTemplate, interface org.springframework.web.client.RestOperations, class org.springframework.http.client.support.InterceptingHttpAccessor, class java.lang.Object]
Caused by: java.lang.instrument.UnmodifiableClassException

[ERROR] testGetGovernanceClassificationDefinitionClientAPIException  Time elapsed: 0.01 s  <<< ERROR!
org.mockito.exceptions.misusing.UnfinishedMockingSessionException:

Unfinished mocking session detected.

It also looked somewhat similar to https://github.com/mockito/mockito/issues/801

As above - somewhat hard to determine where the responsiblities arise between

• J9 project
• AdoptOpenJDK
• Mockito

However the IMPACT to Java Developers is

• Cannot use J9 for development
• Lack of trust in using J9 in production
• Less trust in 'open' initiatives / oracle 'just works ' (licensing issues aside)

Apologies no direct test case yet, but if you could offer some guidance on the best way to proceed I can look at putting a small module together that demonstrates the issue

[pshipton]

I notice class java.lang.Object is in the list of classes. This is one of the classes OpenJ9 does not allow to be modified. https://github.com/eclipse/openj9/blob/7b4ace6a507a7af17b138b1de663caadcee86241/runtime/util/hshelp.c#L3226
@gacholio

[gacholio]

The MacOS build isn't ready for production yet (there are no official releases for JDK8) - it may not even be able to load the JIT yet, which might explain differences in behaviour from Windows (not that there are any intentional differences - all JVMTI features should work equally well on all platforms).

[planetf1]

Thanks for the update. I think a fair conclusion would be that mockito inlining is not expected to work with OpenJ9 due to the attempted class modifications that mockito does for stubbing.

[gacholio]

I would expect it to work if Object was not modified.

[gacholio]

@planetf1 We're working to allow Object to be redefined. Can you provide a reproducible test I can run to very the feature?

[remmeier]

I see it as well in the context of R3 Corda to an app similar https://github.com/corda/cordapp-example. There unfortunately I run into a further issue next to Mockito (https://github.com/puniverse/quasar/issues/321). Our app is closed source unfortunately, but if there is something I could try, you could let me know. Hope run into this issue with cordapp-example as well once the other issue is resolved.

[DanHeidinga]

@remmeier We've merged #4714 which allows redefinition of Object. Would you be able to test an AdoptOpenJDK nightly build later this week to validate this fixes the issue?

[planetf1]

I should be able to test within a couple of days. Let me know when there is a jdk you'd like me to try with. Thanks

[dcendents]

@DanHeidinga I have the same error in one of my project.

I can confirm that the latest nightly OpenJDK8U-jdk_x64_windows_openj9_2019-02-27-11-11.zip works fine and the mockito inline mode does not throw an error.

[DanHeidinga]

Excellent. Glad to hear it's resolved!

[planetf1]

I can confirm I am no longer seeing this either. thanks!