Hi Pankaj,
I'm not sure that the splitting one property change event into two
events would be correct.
Anyway, I don't think that any issues take place in the scenario written
in the bug description. If for some reason the developer decided to
overrides the equals() method to make two list models always equal to
each other then he cannot expect that JList class will continue to treat
those two models as different.
--Semyon
On 02/06/2018 02:22 AM, Pankaj Bansal wrote:
Hi All,
Please review the fix for JDK 11.
Bug:
https://bugs.openjdk.java.net/browse/JDK-6562442
webrev:
http://cr.openjdk.java.net/~pbansal/6562442/webrev.00/
<http://cr.openjdk.java.net/%7Epbansal/6562442/webrev.00/>
Issue:
JList may not set ListModel properly on calling JList.setModel in some
cases.
The ListModel should be checked for equality by reference not by
actual values, while calling JList.setModel. JList.setModel informs
the UI delegate about the change by firing a propertyChange. Now
firePropertyChange checks for equality between the models by calling
equals. This may return a false true, if a subclass of ListModel has
overridden the equals method to test the ListModels for actual values
for some other purpose. This may leave UI delegate in inconsistent state.
Fix:
Made changes in JList.setModel to check for equality by reference and
then call firePropertyChange. In first call to firePropertyChange,
newValue is sent as null, so that ListDataListeners are removed from
the old ListModel. Then new ListModel is set.
In test, for automation, the check is added on number of
ListDataListeners in ListModel as JList.setModel should remove the
listeners from old model and add to new model.
Regards,
Pankaj Bansal
