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

8243115: Spurious invalidations due to bug in IntegerBinding and other classes #198

Open
wants to merge 1 commit into
base: master
from

Conversation

@hjohn
Copy link
Collaborator

@hjohn hjohn commented Apr 27, 2020

This fixes a bug where the first call to unbind would clear the internal invalidation listener used, resulting in subsequent unbind calls to be no-ops, unless bind was called again first.

I had to rewrite the parameterized test slightly as Parameterized will only call the parameters method once, and my new test modifies the internal state of the bindings used as parameters (by doing some unbind calls) which was making other tests fail.


Progress

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

Issue

  • JDK-8243115: Spurious invalidations due to bug in IntegerBinding and other classes

Download

$ git fetch https://git.openjdk.java.net/jfx pull/198/head:pull/198
$ git checkout pull/198

This fixes a bug where the first call to unbind would clear the internal invalidation listener used, resulting in subsequent unbind calls to be no-ops, unless bind was called again first.
@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Apr 27, 2020

👋 Welcome back jhendrikx! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request.

@openjdk openjdk bot added the rfr label Apr 27, 2020
@mlbridge
Copy link

@mlbridge mlbridge bot commented Apr 27, 2020

Webrevs

@kevinrushforth
Copy link
Member

@kevinrushforth kevinrushforth commented Apr 27, 2020

/reviewers 2

@openjdk
Copy link

@openjdk openjdk bot commented Apr 27, 2020

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

@kevinrushforth
Copy link
Member

@kevinrushforth kevinrushforth commented Apr 27, 2020

The title of this PR should match exactly the title of the JBS bug. So:

8243115: Spurious invalidations due to bug in IntegerBinding and other classes
@kevinrushforth kevinrushforth self-requested a review Apr 27, 2020
@kevinrushforth
Copy link
Member

@kevinrushforth kevinrushforth commented Apr 27, 2020

@arapte can you also review this?

@hjohn hjohn changed the title 8243115: Unregister bindings when unbind called multiple times 8243115: Spurious invalidations due to bug in IntegerBinding and other classes Apr 27, 2020
@nlisker
Copy link
Collaborator

@nlisker nlisker commented Apr 27, 2020

I will review this too anyway.

@kevinrushforth
Copy link
Member

@kevinrushforth kevinrushforth commented Apr 28, 2020

I will review this too anyway.

Thank you. That will be helpful.

@nlisker
Copy link
Collaborator

@nlisker nlisker commented May 11, 2020

As I started my review I noticed that unbind does not null-check its argument dependencies like bind does and it can lead to NPEs. If it is out of scope for this PR to fix this, a new issue should be filed.

@nlisker
Copy link
Collaborator

@nlisker nlisker commented May 12, 2020

The fix looks correct and the tests pass. I just wonder why the change to reflection-based construction with bindingMockClassConstructor?

@hjohn
Copy link
Collaborator Author

@hjohn hjohn commented May 12, 2020

The fix looks correct and the tests pass. I just wonder why the change to reflection-based construction with bindingMockClassConstructor?

The Parameterized test constructs some standard Binding objects to run multiple tests with. This works fine if those objects are immutable (or aren't modified during the tests). My new test however does modify them, and other tests would fail with such modified objects (as unbind was called on some). So I rewrote this a little bit to construct fresh objects for each test, and for that I used some reflection magic to avoid having to write a specific test for each of the 8 binding types.

@hjohn
Copy link
Collaborator Author

@hjohn hjohn commented May 12, 2020

As I started my review I noticed that unbind does not null-check its argument dependencies like bind does and it can lead to NPEs. If it is out of scope for this PR to fix this, a new issue should be filed.

I'm fine with doing a fix, but I need to know which one. Avoiding NPE's and silently doing nothing is IMHO not very desirable as this will give the user of the API no feedback that something went wrong.

So I would prefer to fix this by documenting that these cases will result in a NPE.

The bind method has a similar issue -- it doesn't check its array elements for null, and will throw a NPE when attempting to add a listener to null. Again, I would just document the NPE so what is clearly a mistake doesn't go unnoticed.

@nlisker
Copy link
Collaborator

@nlisker nlisker commented May 12, 2020

I'm fine with doing a fix, but I need to know which one. Avoiding NPE's and silently doing nothing is IMHO not very desirable as this will give the user of the API no feedback that something went wrong.

So I would prefer to fix this by documenting that these cases will result in a NPE.

The bind method has a similar issue -- it doesn't check its array elements for null, and will throw a NPE when attempting to add a listener to null. Again, I would just document the NPE so what is clearly a mistake doesn't go unnoticed.

I think that checking the array elements doesn't help much because by the time you can check them they will already be used, and that will throw an NPE implicitly.

bind is no-op for null or 0-length arrays, but should have probably throw an NPE on the null case. The 0-length check saves creating the observer, so I think it makes sense. unbind should probably only throw an NPE on null arrays, but that happens implicitly anyway, so maybe there is no change needed unless it's for clarity because we can add a custom error message.

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

Successfully merging this pull request may close these issues.

None yet

3 participants