I wonder what java spec you are reading.. There would be no point in having a hashcode override anywhere if it would not check the fields of that object as the object itself has no data (except maybe a C++ pointer value or something allocated by the JVM implementations, which is what the unoverridden hashcode returns).

Also Object.hashCode javadoc does state:
” The general contract of hashCode is:

Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application.
If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.
…
“
If you are calling DataValue.setValue you are changing the information (the value) which affects the equals comparison (i.e. the DataValue is not anymore the same, you just changed it’s value), therefore the hashcode is also different.

I would say you are in most cases better creating new DataValue than trying to change the value of an existing one

Also note that that class is part of the Java Stack, not the SDK.

– Bjarne

You do have wrong assumpion on how have hashcodes works in java, i.e. it works like that in _every_ java class (that overrides the default hashcode/equals implementations in Object, which ,must be done so that the equal check works for different instances of the object and is not pure implementation pointer comparison), if you change something that the object would not be equal to it’s previous state, of course the hashcode changes (unless for a rare occuranse of hash collision). Also note that if 2 java objects are .equals then they are required to have same hashcode. Also if objects have the same hashcode, they are not necessarily equal (because the hashcode is just a hash). A hashcode implementation of return 0; would be valid (a naive implementation, but still valid).

You are not supposed to use something which hashcode can change in a “hashcode-aware” Collection. However note that unless you are doing something weird (like calling .setValue), the hashcode of the DataValue does/should not change if you are using the SDK API. Note that DataValue is used as “return by refence” style in some listener style APIs where you need to call .setValue on the DataValue given as parameter to the listener method (assuming you are starting out with the SDK it is unlikely that you need to do these).

Now for the more interesting part: why would you like to change the value in a DataValue? I see no reason why.
As a technical note most likely the reason why the method exist: I believe that is because of how the opc.tcp binary serialization is implemented

In a sense you do have a valid point, I would much prefer that the DataValue would be immutable and could not be changed. However the current implementation is what it is and changing that would break too many existing code so it most likely wont be changed.

– Bjarne