-
Notifications
You must be signed in to change notification settings - Fork 6.2k
8341982: Simplify JButton/bug4323121.java #21475
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
8341982: Simplify JButton/bug4323121.java #21475
Conversation
|
👋 Welcome back aivanov! A progress list of the required criteria for merging this PR into |
|
@aivanov-jdk 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: 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 no new commits pushed to the ➡️ To integrate this PR with the above commit message to the |
|
@aivanov-jdk The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
DamonGuy
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test looks good still. Changes made do clean up the look of the test's code a lot.
| private static final CountDownLatch mouseEntered = new CountDownLatch(1); | ||
|
|
||
| // Usage of this flag is thread-safe because of using the mouseEntered latch | ||
| private static boolean modelArmed; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should it be volatile?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it shouldn't: “this flag is thread-safe because of using the mouseEntered latch”.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok.
Co-authored-by: Abhishek Kumar <abhishek.cx.kumar@oracle.com>
kumarabhi006
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Verified the test and look good to me.
| throw new RuntimeException("Window didn't gain focus"); | ||
| } | ||
| robot.waitForIdle(); | ||
| robot.delay(1000); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new code probably should follow the same pattern, flush all events/commands to native by the waitForIdle. and then wait response from OS for 1_or_less second.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reversed the order because window may gain focus before all the events are processed.
To ensure all the events in the queue are handled, I added robot.waitForIdle().
The next action in the test is to get location of the button, which can be done safely since the frame must be displaying on the screen because it has already received windowGainedFocus event.
For this reason, there's no need for robot.delay(1000).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test follows the same pattern that I used in #21474:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To ensure all the events in the queue are handled, I added
robot.waitForIdle().
This will flush events which were posted after the windows gained focus, but before the patch the test flushed all events (including event to show the window which might be asynchronous). My point is that this operation might be longer that 1 second(one of the reason we have all that deleyas). So we should waitForIdle first, then wait via delay or other sync_ops.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will flush all the pending events in the queue, which includes events that were posted before the windowGainedFocus latch is released as well as events are posted afterwards.
There's no difference whether I place waitForIdle before or after.
If I place robot.waitForIdle before windowGainedFocus.await, then await immediately returns, that is the delay added by await is zero.
If I place robot.waitForIdle after windowGainedFocus.await, the main thread stops until the window gained focus event is delivered, after which robot.waitForIdle flushes the remaining events in the queue.
In both cases, there's a slight possibility windowGainedFocus is never triggered if the window didn't get focus for whatever reason…
On my Windows 11 laptop, the average time (over 20 runs of the bug4323121 test)
- for
windowGainedFocus.await: 12 ms - for
robot.waitForIdle: 36 ms - or cumulatively: 48 ms
If I change the order of calls,
- for
robot.waitForIdle: 51 ms - for
windowGainedFocus.await: 0 ms - or cumulatively: 51 ms
Both versions align well — robot.waitForIdle takes about 50 ms. (The version where waitForIdle follows await is slightly quicker because await does nothing at all whereas waitForIdle posts events from its own copy of the queue for handling.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there's no difference, I see no reason to complicate the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mrserb Are any more concerns with the updated code in JButton/bug4323121.java?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
honkar-jdk
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
| public void mouseClicked(MouseEvent e) { | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extra newline
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't get where you wanted to add a blank line…
kumarabhi006
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
|
/integrate |
|
Going to push as commit 6fa5cea.
Your commit was automatically rebased without conflicts. |
|
@aivanov-jdk Pushed as commit 6fa5cea. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
The test
javax/swing/JButton/bug4323121.javacontains lots of unused methods.I removed all the unused methods by extending
MouseAdapter.I use
CountDownLatchto synchronise actions in the test.The test still verifies
button.getModel().isArmed()doesn't always returntruefor classes which extendJButton. I verified the updated test fails in 1.3.0 and passes in 1.4.0, so the test still reproduces the original problem.Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/21475/head:pull/21475$ git checkout pull/21475Update a local copy of the PR:
$ git checkout pull/21475$ git pull https://git.openjdk.org/jdk.git pull/21475/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 21475View PR using the GUI difftool:
$ git pr show -t 21475Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/21475.diff
Using Webrev
Link to Webrev Comment