Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8267505: {List,Set,Map}PropertyBase::bind should check against identity #516

Closed

Conversation

@jperedadnr
Copy link
Collaborator

@jperedadnr jperedadnr commented May 24, 2021

ListPropertyBase::bind, SetPropertyBase::bind, MapPropertyBase::bind have a check on whether a different instance of the observable is the same, and this PR changes that to check against identity.

Tests are included.


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8267505: {List,Set,Map}PropertyBase::bind should check against identity

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jfx pull/516/head:pull/516
$ git checkout pull/516

Update a local copy of the PR:
$ git checkout pull/516
$ git pull https://git.openjdk.java.net/jfx pull/516/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 516

View PR using the GUI difftool:
$ git pr show -t 516

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jfx/pull/516.diff

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented May 24, 2021

👋 Welcome back jpereda! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot added the rfr label May 24, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented May 24, 2021

Webrevs

@kevinrushforth
Copy link
Member

@kevinrushforth kevinrushforth commented May 24, 2021

This seems like the right fix to me, but it begs the question of why .equals() was used in the first place when these classes were created. It's possible that it was just a mistake. Can you think of any cases where two sets that are not the same object, but are equals should be treated as the same for the purpose of checking whether to unbind? I can't, but want to take a closer look.

/reviewers 2

@openjdk
Copy link

@openjdk openjdk bot commented May 24, 2021

@kevinrushforth
The number of required reviews for this PR is now set to 2 (with at least 1 of role reviewers).

@jperedadnr
Copy link
Collaborator Author

@jperedadnr jperedadnr commented May 24, 2021

Having a look at the equals implementation in ReadOnly{List/Set/Map}Property, it is oriented to check the contents of the collection. For the List case, for instance, List::equals javadoc clearly states that

two lists are defined to be equal if they contain the same elements in the same order

While this makes sense in many cases, it doesn't for binding a {List/Set/Map}PropertyBase, as we don't bind each collection's items one by one, but the collections themselves.

In this case, calling:

c.bind(a);
c.bind(b);

over two different collections, even if they have the exact same content, would necessary imply a change of observables, and the need to unbind first the old binding and update the observable/listener accordingly. If later on b is modified, but not a, it would be expected that c will react to those changes. However, that is not happening as equals is currently preventing it.

So I can't see a possible use case for this.

Copy link
Member

@Maran23 Maran23 left a comment

Looks good. Verified tests failing before and succeed after the fix.

One side note which might explaing, why equals was used: The super class ReadOnlyList/Set/MapProperty have hashcode/equals overridden, where equals accepts the corresponding collection (List/Set/Map), which is then checked against the collection the property has set.

This is fine, although it looks a bit weird at first as the equals expects a collection, not a property. But it makes sense as all those classes implements the corresponding collection interface (List/Map/Set).

And a quick look in the history is showing, that at first the equals was really checking for a property (and in there: bean and name), which makes normalList.equals(listProperty) never work. So maybe this is leftover code from the old implementaation.

@openjdk
Copy link

@openjdk openjdk bot commented Jun 4, 2021

@jperedadnr This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8267505: {List,Set,Map}PropertyBase::bind should check against identity

Reviewed-by: mhanl, kcr

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 9 new commits pushed to the master branch:

  • 47700d8: 8267819: CoInitialize/CoUninitialize should be called on same thread
  • 526f990: 8239138: StyleManager should use a BufferedInputStream
  • 5e6d442: 8267892: Add .gitattributes to repo
  • 7b7050c: 8267314: Loading some animated GIFs fails with ArrayIndexOutOfBoundsException: Index 4096 out of bounds for length 4096
  • a645b5a: 8252783: Remove the css Selector and ShapeConverter constructors
  • 329013b: 8267621: Mark HonorDeveloperSettingsTest as unstable on Linux
  • 24ffe35: 8265210: TreeCell: cell editing state not updated on cell re-use
  • 9507ea4: 8264140: Add -Djava.security.manager=allow to JavaFX tests calling setSecurityManager
  • 2fd5092: 8263761: Update boot JDK to 16.0.1

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready label Jun 4, 2021
@jperedadnr
Copy link
Collaborator Author

@jperedadnr jperedadnr commented Jun 5, 2021

/integrate

@openjdk openjdk bot closed this Jun 5, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Jun 5, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Jun 5, 2021

@jperedadnr Since your change was applied there have been 11 commits pushed to the master branch:

  • fe81b9c: 8268120: Allow hardware cursor to be used on Monocle-EGL platforms
  • ee03238: 8268152: gstmpegaudioparse does not provides timestamps for HLS MP3 streams
  • 47700d8: 8267819: CoInitialize/CoUninitialize should be called on same thread
  • 526f990: 8239138: StyleManager should use a BufferedInputStream
  • 5e6d442: 8267892: Add .gitattributes to repo
  • 7b7050c: 8267314: Loading some animated GIFs fails with ArrayIndexOutOfBoundsException: Index 4096 out of bounds for length 4096
  • a645b5a: 8252783: Remove the css Selector and ShapeConverter constructors
  • 329013b: 8267621: Mark HonorDeveloperSettingsTest as unstable on Linux
  • 24ffe35: 8265210: TreeCell: cell editing state not updated on cell re-use
  • 9507ea4: 8264140: Add -Djava.security.manager=allow to JavaFX tests calling setSecurityManager
  • ... and 1 more: https://git.openjdk.java.net/jfx/compare/aebac072b1919e68f7732de929dc085d00c62e92...master

Your commit was automatically rebased without conflicts.

Pushed as commit 59cf4de.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants