module java.base does not "opens java.util.concurrent.atomic" to unnamed module

[massdosage]

Hello there,

I have a test using EqualsVerifier (thanks so much for this library and for keeping it up to date!) which runs fine on Java 8 and Java 11 but fails on Java 17 with an error like so:

`[ERROR] GapCoverageSpecification.Good POJOs:64 Condition failed with Exception:

TestHelperRoutines.goodPojo(DecisionV1, true)
| | |
| | class com.whiteops.fact.api.schema.v1.DecisionV1
| java.lang.AssertionError: EqualsVerifier found a problem in class com.whiteops.fact.api.schema.v1.DecisionV1.
| -> Unable to make field volatile long java.util.concurrent.atomic.Striped64$Cell.value accessible: module java.base does not "opens java.util.concurrent.atomic" to unnamed module @4f47d241
|
| For more information, go to: https://www.jqno.nl/equalsverifier/errormessages
| (EqualsVerifier 3.14.1, JDK 17.0.7 on Mac OS X)
| at nl.jqno.equalsverifier.api.SingleTypeEqualsVerifierApi.verify(SingleTypeEqualsVerifierApi.java:316)
| at com.whiteops.jframework.test.TestHelperRoutines.validateEquals(TestHelperRoutines.java:208)
| at com.whiteops.jframework.test.TestHelperRoutines.validateEquals(TestHelperRoutines.java:188)
| at com.whiteops.jframework.test.TestHelperRoutines.goodPojo(TestHelperRoutines.java:173)
| at GapCoverageSpecification.Good POJOs(GapCoverageSpecification.groovy:64)
| Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field volatile long java.util.concurrent.atomic.Striped64$Cell.value accessible: module java.base does not "opens java.util.concurrent.atomic" to unnamed module @4f47d241
| at nl.jqno.equalsverifier.internal.reflection.FieldModifier.change(FieldModifier.java:112)
| at nl.jqno.equalsverifier.internal.reflection.FieldModifier.changeField(FieldModifier.java:100)
| at nl.jqno.equalsverifier.internal.reflection.InPlaceObjectAccessor.scramble(InPlaceObjectAccessor.java:52)
| at nl.jqno.equalsverifier.internal.reflection.ClassAccessor.getRedAccessor(ClassAccessor.java:188)
| at nl.jqno.equalsverifier.internal.reflection.ClassAccessor.getRedObject(ClassAccessor.java:177)
| at nl.jqno.equalsverifier.internal.prefabvalues.factories.FallbackFactory.giveInstances(FallbackFactory.java:95)
| at nl.jqno.equalsverifier.internal.prefabvalues.factories.FallbackFactory.createValues(FallbackFactory.java:40)`

This is using version 3.14.1 and I also tried the -nodep version. I don't know where the Striped64$Cell.value is coming from as that doesn't appear as a type in the POJO I'm checking. I also don't see anything clearly "wrong" in the EqualsVerifier code. Any clue what could be going wrong here?

[jqno]

Thanks for the kind words!

It's probably a field from the Java APIs that you use in your class that I haven't added a prefab value for yet. Can you show me your DecisionV1 class?

[massdosage]

I'm afraid I can't as it's not in an open source project. Let me know what I should look for and I can go digging in it and it's parent classes.

[jqno]

I did some digging in the Java sources, looks like Striped64 is a common super class for LongAdder and LongAccumulator, and their Double counterparts. Do you use those in your class somewhere? Or perhaps something else from java.util.concurrent.atomic?

[massdosage]

Would I be looking for values used in non-private getters and setters for the class and its parent classes?

[jqno]

Yes, any fields used in the class and its supetclass(es), both private and public, and also static, including constants that are both static and final.

[massdosage]

Ah, this might be the culprit protected transient Meter which is of type com.codahale.metrics.Meter which in turn has a field of type java.util.concurrent.atomic.LongAdder.

[jqno]

That's probably it. You can use addPrefabValue with either Meter or LongAdder, and that should solve it.

I'll also add LongAdder and friends to the builtin list in a new version of EqualsVerifier, you could also wait for that if you prefer. But I don't know when I'll have time to actually do that; it might be a few days.

[jqno]

I can make a release tomorrow morning (European time), if you prefer to wait for that!

[massdosage]

No rush, rather do it the way you think is best. We can wait a few days as we have a workaround in place. Thanks for looking into this so quickly. Let me know if you want me to create an issue for it.

[jqno]

I've just released version 3.14.2, which should solve this.

[massdosage]

Fantastic, I've been away but will try give this a go this week and confirm. Bedankt!

[massdosage]

I can confirm this resolves the issue. Thanks again.