Skip to content

Conversation

@rajamah
Copy link
Member

@rajamah rajamah commented Mar 10, 2025

Added code to Iterates over all installed Look and Feel environments and added related exception handling.

Testing done.


Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue

Issue

  • JDK-8280818: Expand bug8033699.java to iterate over all LaFs (Enhancement - P4)

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/23964/head:pull/23964
$ git checkout pull/23964

Update a local copy of the PR:
$ git checkout pull/23964
$ git pull https://git.openjdk.org/jdk.git pull/23964/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 23964

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/23964.diff

Using Webrev

Link to Webrev Comment

@bridgekeeper
Copy link

bridgekeeper bot commented Mar 10, 2025

👋 Welcome back rmahajan! 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
Copy link

openjdk bot commented Mar 10, 2025

@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:

8280818: Expand bug8033699.java to iterate over all LaFs

Reviewed-by: dnguyen, aivanov, honkar, abhiscxk

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 master branch:

  • 37ec796: 8351500: G1: NUMA migrations cause crashes in region allocation
  • 4e51a8c: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long)
  • 7e3bc81: 8351216: ZGC: Store NUMA node count
  • 82eb780: 8351349: GSSUtil.createSubject has outdated access control context and policy related text
  • c3db667: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special optimization settings
  • 375722f: 8351839: RISC-V: Fix base offset calculation introduced in JDK-8347489
  • 4c5956d: 8350866: [x86] Add C1 intrinsics for CRC32-C
  • 9c00331: 8330469: C2: Remove or change "PrintOpto && VerifyLoopOptimizations" as printing code condition
  • c18494d: 8351108: ImageIO.write(..) fails with exception when writing JPEG with IndexColorModel
  • 86860ca: 8346916: [REDO] align_up has potential overflow
  • ... and 186 more: https://git.openjdk.org/jdk/compare/9ec46968fbfddf99a8349cb6903d24b1c2fdaf1d...master

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 /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

@openjdk openjdk bot added the rfr Pull request is ready for review label Mar 10, 2025
@openjdk
Copy link

openjdk bot commented Mar 10, 2025

@rajamah The following label will be automatically applied to this pull request:

  • client

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.

@openjdk openjdk bot added the client client-libs-dev@openjdk.org label Mar 10, 2025
@mlbridge
Copy link

mlbridge bot commented Mar 10, 2025

Webrevs

Copy link
Contributor

@kumarabhi006 kumarabhi006 Mar 11, 2025

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

  1. mainFrame = new JFrame("Bug 8033699 - 9 Tests for Grouped / Non-Grouped Radio Buttons");
  2. Non group can be changed to non-group (For consistency across test)
  3. Please limit to 80 cols wherever applicable

Otherwise the changes look good. Verified test on macOS and it works as expected.

Copy link
Member Author

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 ?

Copy link
Contributor

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.

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member Author

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

Copy link
Contributor

@DamonGuy DamonGuy left a 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.

Comment on lines +130 to +131
} catch (ClassNotFoundException | InstantiationException |
IllegalAccessException | UnsupportedLookAndFeelException e) {
Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Member

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;
Copy link
Contributor

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.

Copy link
Member

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.

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.

Copy link
Contributor

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.

Copy link
Member

@aivanov-jdk aivanov-jdk left a 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.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Mar 12, 2025
Copy link
Contributor

@kumarabhi006 kumarabhi006 left a 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.

@rajamah
Copy link
Member Author

rajamah commented Mar 13, 2025

/integrate

@openjdk openjdk bot added the sponsor Pull request is ready to be sponsored label Mar 13, 2025
@openjdk
Copy link

openjdk bot commented Mar 13, 2025

@rajamah
Your change (at version 65d95ac) is now ready to be sponsored by a Committer.

@aivanov-jdk
Copy link
Member

/sponsor

@openjdk
Copy link

openjdk bot commented Mar 13, 2025

Going to push as commit b50fe9b.
Since your change was applied there have been 198 commits pushed to the master branch:

  • 771e160: 8351323: Parameterize compiler and linker flags for iconv
  • 0ff1c08: 8349984: (jdeps) jdeps can use String.repeat instead of String.replaceAll
  • 37ec796: 8351500: G1: NUMA migrations cause crashes in region allocation
  • 4e51a8c: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long)
  • 7e3bc81: 8351216: ZGC: Store NUMA node count
  • 82eb780: 8351349: GSSUtil.createSubject has outdated access control context and policy related text
  • c3db667: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special optimization settings
  • 375722f: 8351839: RISC-V: Fix base offset calculation introduced in JDK-8347489
  • 4c5956d: 8350866: [x86] Add C1 intrinsics for CRC32-C
  • 9c00331: 8330469: C2: Remove or change "PrintOpto && VerifyLoopOptimizations" as printing code condition
  • ... and 188 more: https://git.openjdk.org/jdk/compare/9ec46968fbfddf99a8349cb6903d24b1c2fdaf1d...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Mar 13, 2025
@openjdk openjdk bot closed this Mar 13, 2025
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review sponsor Pull request is ready to be sponsored labels Mar 13, 2025
@openjdk
Copy link

openjdk bot commented Mar 13, 2025

@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.

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

Labels

client client-libs-dev@openjdk.org integrated Pull request has been integrated

Development

Successfully merging this pull request may close these issues.

5 participants