-
Notifications
You must be signed in to change notification settings - Fork 6.2k
8280818: Expand bug8033699.java to iterate over all LaFs #23964
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
Conversation
|
👋 Welcome back rmahajan! A progress list of the required criteria for merging this PR into |
|
@rajamah 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 196 new commits pushed to the
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. As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@DamonGuy, @aivanov-jdk, @honkar-jdk, @kumarabhi006) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
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.
Minor changes can be done
- mainFrame = new JFrame("Bug 8033699 -
9Tests forGrouped / Non-GroupedRadio Buttons"); - Non group can be changed to non-group (For consistency across test)
- Please limit to 80 cols wherever applicable
Otherwise the changes look good. Verified test on macOS and it works as expected.
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 these be done as part of this change or a separate bug for refactoring /code cleanup of this test ?
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 usually fix these when I touch the test anyway.
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.
mainFrame = new JFrame("Bug 8033699 - 9 Tests for Grouped / Non-Grouped Radio Buttons");
Makes sense… However, a generic title would be good enough. Something like “Radio button focus tests”. The current title is too long, it doesn't fit in the title bar of the frame (at least on Windows), therefore I see no point in making it comprehensive and long.
I usually fix these when I touch the test anyway.
In majority of cases, I do too. Yet I tend not to change lines that I don't touch. From this point of view, additional changes aren't necessary — none of the lines that don't fit into 80-column limit aren't touched.
The problem I see with additional refactoring is that it adds noise to the code review and it makes it harder to understand what the real, important changes are.
Use your common sense.
Please limit to 80 cols wherever applicable
This is not applied strictly… I'm for following the 80-column limit where it doesn't reduce the readability. Yet I'm for stronger enforcement of 100-column limit. There are quite a few lines which are longer than 100 columns. The culprit is KeyboardFocusManager.getCurrentKeyboardFocusManager().getFocusOwner() which accounts for 70 characters.
I'd like to make it shorter, and the focus manager can be cached after the first usage. At the same time, I'm unsure doing so in this code review is reasonable.
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.
In short, I'd rather avoid doing additional refactoring, except for changing the frame title if Rajat wants to, because none of the lines that need updating are not touched by the current changes.
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 have filed a new bug to incorporate the suggestions here and re-factor test code separately - JDK-8351884
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.
I also tested this and the test passes consistently on all LAFs.
| } catch (ClassNotFoundException | InstantiationException | | ||
| IllegalAccessException | UnsupportedLookAndFeelException 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.
This can just be set to Exception e rather than expanding it into separate exceptions.
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 provides more targeted error messages and logging.
If you catch a broad Exception, you might inadvertently mask other unexpected errors that should be investigated.
Separate exception handlers make it easier to identify the root cause of an issue.
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'm fine with separate types.
You re-throwing any of the exceptions wrapped into RuntimeException. From this point of view, a single Exception won't change anything: if an exception is thrown, it's caught and re-thrown. These four exceptions are the only checked exceptions that can be thrown, catching Exception will catch them either way.
Either way is fine with me.
| SwingUtilities.invokeAndWait(() -> { | ||
| if (mainFrame != null) { | ||
| mainFrame.dispose(); | ||
| mainFrame = null; |
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.
Assigning mainFrame = null is not required since we are disposing the frame at this point.
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.
Assigning
mainFrame = nullis not required since we are disposing the frame at this point.
It's required here, because the loop is repeated, and setting mainFrame to null prevents access to a disposed frame… likely from disposing of the frame again.
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.
Missed seeing the finally block is within the LaF loop. Looks fine then.
aivanov-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.
Looks good to me.
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.
Good to have a separate bug for re-factoring. Otherwise, looks good to me.
|
/integrate |
|
/sponsor |
|
Going to push as commit b50fe9b.
Your commit was automatically rebased without conflicts. |
|
@aivanov-jdk @rajamah Pushed as commit b50fe9b. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Added code to Iterates over all installed Look and Feel environments and added related exception handling.
Testing done.
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/23964/head:pull/23964$ git checkout pull/23964Update a local copy of the PR:
$ git checkout pull/23964$ git pull https://git.openjdk.org/jdk.git pull/23964/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 23964View PR using the GUI difftool:
$ git pr show -t 23964Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/23964.diff
Using Webrev
Link to Webrev Comment