Skip to content

8359430: Test 'javax/swing/plaf/windows/bug4991587.java' automatically failed on Windows 2025 x64 with message "Failed. Compilation failed: Compilation failed" #25883

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.

Sign up for GitHub

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

Open
wants to merge 11 commits into
base: master
Choose a base branch
from
+3 −20
Open

8359430: Test 'javax/swing/plaf/windows/bug4991587.java' automatically failed on Windows 2025 x64 with message "Failed. Compilation failed: Compilation failed" #25883

Changes from all commits
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
c51406a
Initial commit for backout
DamonGuy Nov 24, 2024
a98fb87
Merge branch 'master' of github.com:DamonGuy/jdk
DamonGuy Nov 26, 2024
947f73d
Merge branch 'master' of github.com:DamonGuy/jdk
DamonGuy Jan 13, 2025
b17e483
Merge branch 'master' of github.com:DamonGuy/jdk
DamonGuy Mar 24, 2025
9583f8a
Merge branch 'master' of github.com:DamonGuy/jdk
DamonGuy Apr 15, 2025
d76baf5
Merge branch 'master' of github.com:DamonGuy/jdk
DamonGuy Apr 16, 2025
abd6ab9
Merge branch 'master' of github.com:DamonGuy/jdk
DamonGuy Apr 22, 2025
0824a98
Merge branch 'master' of github.com:DamonGuy/jdk
DamonGuy May 8, 2025
781a2ba
Merge branch 'master' of github.com:DamonGuy/jdk
DamonGuy Jun 9, 2025
e1d4caa
Initial commit
DamonGuy Jun 17, 2025
6325561
Update test to not extend ButtonUI
DamonGuy Jun 18, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 3 additions & 20 deletions test/jdk/javax/swing/plaf/windows/bug4991587.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,15 +34,11 @@

import java.awt.Color;
import java.awt.FlowLayout;
import java.awt.Graphics;
import java.awt.Rectangle;

import javax.swing.AbstractButton;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.UIManager;

import com.sun.java.swing.plaf.windows.WindowsButtonUI;
import javax.swing.border.LineBorder;

public class bug4991587 {
static final String INSTRUCTIONS = """
Expand All @@ -69,27 +65,14 @@ static JFrame createUI() {
f.setSize(400, 100);

JButton button1 = new JButton("\u0114 Enabled JButton");
button1.setUI(new MyButtonUI());
button1.setBorder(new LineBorder(Color.BLUE));
f.add(button1);

JButton button2 = new JButton("\u0114 Disabled JButton");
button2.setEnabled(false);
button2.setUI(new MyButtonUI());
button2.setBorder(new LineBorder(Color.BLUE));
f.add(button2);

return f;
}

static class MyButtonUI extends WindowsButtonUI {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use composition here: extend BasicButtonUI, create a WindowsButtonUI¹ object and forward all the methods² to the instance of WindowsButtonUI. In the paintText method, draw the rectangle and then call the implementation of your WindowsButtonUI.

¹ Use WindowsButtonUI.createUI to create an instance.
² All the overridden methods in WindowsButtonUI.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good if we could eliminate the reference to WindowsButtonUI. It might also be useful to check the behavior across all L&Fs.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good if we could eliminate the reference to WindowsButtonUI.

But we want the regression to reproduce the original problem. The problem was specific to WindowsButtonUI, in WindowsGraphicsUtils according to comments in the bug.

It may be impossible to reproduce the problem without referencing WindowsButtonUI. If it's possible, I'm all for it.

It might also be useful to check the behavior across all L&Fs.

The bug was in Windows L&F, I don't think it's applicable to other L&F.

On Windows, the disabled text was painted with “shadow” with offset of (1, 1) which could be painted over another part of the button. Other L&Fs are free to paint the button differently.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may be impossible to reproduce the problem without referencing WindowsButtonUI. If it's possible, I'm all for it.

That should be checked on old jdk build.

The bug was in Windows L&F, I don't think it's applicable to other L&F.

It depends on how these offsets were used previously, maybe we displayed the text outside the button, which shouldn't happen for all L&Fs.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may be impossible to reproduce the problem without referencing WindowsButtonUI. If it's possible, I'm all for it.

That should be checked on old jdk build.

Exactly!

We have to reproduce the original bug first to see what was wrong.

The bug was in Windows L&F, I don't think it's applicable to other L&F.

It depends on how these offsets were used previously, maybe we displayed the text outside the button, which shouldn't happen for all L&Fs.

Yes, but…

This specific bug was for Windows only, the fix was presumably in Windows-only code, this is why I don't care much about other L&F.

Even if the text was displayed outside of the button, it was Windows-specific.

Until we understand what the original bug was, it is too early to extend the test to other L&F.

Additionally, it's a manual test. If the test is automated, it makes more sense to test for all L&Fs; for a manual test, I'd rather avoid testing in other L&F because the bug never existed there.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This specific bug was for Windows only, the fix was presumably in Windows-only code, this is why I don't care much about other L&F.

It does not matter where the bug was if it can be reproduced via the public API. It is quite common for a test written for one platform later catch a bug on another.

Even if the text was displayed outside of the button, it was Windows-specific.
How do we know that if we did not run the test on non-windows platforms?

Additionally, it's a manual test. If the test is automated, it makes more sense to test for all L&Fs; for a manual test, I'd rather avoid testing in other L&F because the bug never existed there.

For a manual test it is unnecessary but I think it should be possible to automate. And checking of all L&F depends only on how the bug can be triggered and what is wrong.

protected void paintText(Graphics g, AbstractButton b,
Rectangle textRect, String text) {
g.setColor(Color.blue);
g.drawRect(textRect.x,
textRect.y,
textRect.width + 1, // add 1 for the shadow, otherwise it
// will be painted over the textRect
textRect.height);
super.paintText(g, b, textRect, text);
}
}
}