I have instances of Map<Long, Optional<Throwable>> (instantiated using ImmutableMap.of/copyOf from other representations such as HashMap). The instances look identical when debugging, and I'm trying to use .equals to compare in unit tests. I think I might have tracked down the issue, but wanted to confirm.
https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html
This is a value-based class; use of identity-sensitive operations (including reference equality (==), identity hash code, or synchronization) on instances of Optional may have unpredictable results and should be avoided.
From what I've read the implementation for Map equality in most cases relies on the hashcode implementation of (at least?) the value parameter, so I'm thinking this might be why the .equals call is failing here. Since it says "may have" though, I'm interested to know if this should still work in the basic use case and that caveat is more for some specific edge cases, or if this is definitely the reason why.
(I should also maybe point out I'm using the default equals/hashcode implementations provided by eclipse source code generator)
This is a value-based class; use of identity-sensitive operations (including reference equality (==), identity hash code, or synchronization) on instances of Optional may have unpredictable results and should be avoided.
The problem you're citing does not exist yet. The warning is a preparation for value bases classes which may come in Java 10 or later.
It's unclear what's your problem, but it's surely less exotic. These are the common pitfalls (partly taken from the comments):
int and longThrowable and Optional<Throwable>: they must never be equalThrowables: as they usually implement no equals, this is pretty pointlessI'd suggest to create a simple class containing the relevant fields from Throwable and use it instead.