No property change happens when a value is explicitly set to NaN that was undefined before

[draeger]

When listening to changes in a model, the TreeNodeChangeListener is activated when a previously undefined double value is explicitly set to NaN but then nothing happens because we are comparing the old value with the new value using a call to the equals method here. Appearantly, undefined values are NaN behind the scenes. The setValue method still notices the difference and calls the change listeners because there the difference is identified using an != operator (see here).

My suggestion for a fix would be to change the check in AbstractTreeNode so that in addition to !equals also a check via != is performed, i.e.,

else if ((oldValue != null) && (!oldValue.equals(newValue) || oldValue != newValue))

Could such a change have any unwanted effects, too?

[dyrpsf]

Hi @draeger,

I’ve opened PR #273 that extends the firePropertyChange logic in AbstractTreeNode
to handle the case where a previously undefined double (internally NaN) is explicitly
set to NaN.

Concretely, the else if condition now checks both equals() and !=:

else if ((oldValue != null) &&
         (!oldValue.equals(newValue) || oldValue != newValue)) {
  changeType = 2; // real property change
}

This causes a property change event to be fired even when equals() returns true
(e.g. NaN vs NaN), which addresses the behavior described in this issue.

I verified the change by building JSBML and running the core tests:

mvn test -pl core -am