mbien commented on PR #8799: URL: https://github.com/apache/netbeans/pull/8799#issuecomment-3272339288
this essentially boils down to the question what type of client code we want to break. The introduction of [value based](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/doc-files/ValueBased.html#Value-basedClasses) objects has the potential to break things for everyone who expected them to have object identity. in this case here: a) There is code which follows the rules, **looks at the API**, sees keys of type `Object` and treats them as keys of undefined type. In that case, both `choice.equals(JOptionPane.YES_OPTION)` and `(Integer) dd.getValue()` instances would rely on unspecified impl details which were not mentioned anywhere in the doc. What you could see however is code which relies that [OK and YES option would have different key Object identities](https://github.com/neilcsmith-net/netbeans/blob/2c9230058bf194fe6ce05a01518b4143a16624ba/platform/core.windows/src/org/netbeans/core/windows/services/NbPresenter.java#L664-L668). b) And there is code which **looks at the NB impl**, or looks at the keys in the debugger, sees that they are of type `Integer` and that they were derived from `JOptionPane` keys and assumes `impl==spec`. if we want to keep code of kind a) working, but are ok to break b) then we have to replace the `new Integer()` box, with something of arbitrary type but future proof, which behaves exactly like the old `Integer` box. Object identity wise (==) and follows the POJO rules (`.equals()` etc). (serialization is where things would get ugly) If we say that too many looked at the source code and took impl details for granted (b)), we break the object identity of the keys and let `YES==OK` which wasn't the case until this change is made. I do gravitate most of the time to the simpler solution, so I am slightly in favor of simply mapping everything to `JOptionPane` keys as done here, this will avoid breaking code of kind b) but has the (hopefully low) chance to break code of kind a). It always hurts a bit to break good behaving code, but in this case it might be the lesser evil. (when I worked on https://github.com/apache/netbeans/pull/8391 and https://github.com/apache/netbeans/pull/8407 I obviously tried the simple options first too as seen in the PR history, I just saw the failing tests as bad omen for code assumptions and compatibility) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
