-
Bug
-
Resolution: Fixed
-
P4
-
1.2.2
-
012
-
x86
-
windows_nt
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2028144 | 1.3.0 | Prs Prs | P4 | Resolved | Fixed | kestrel |
###@###.### 1999-07-14
There's a race condition introduced in 1.2.2. When a Dialog is
created and its background color is not specified, then under certain
conditions Dialog could inherit background color from its owner
instead of using the system default color (SystemColor.control).
Test case follows.
import java.awt.*;
import java.awt.event.*;
public class Test {
public static void main(String[] args) {
Frame f = new Frame("Frame");
Dialog d = new Dialog(f, "Dialog");
f.setBounds(20, 20, 150, 50);
f.setBackground(Color.yellow);
f.setVisible(true);
d.setBounds(50, 50, 150, 50);
d.setVisible(true); // null bg => should use system default
}
}
If test case is run using installed JDK, the outcome of the race will
almost always be in our favour and the dialog will come up gray, as it
should be. However if JDK is on a remote drive, e.g. NFS mounted
workspace, the it's much easier for the worng thread to win the race
and the dialog will come up yellow (owner's bg). I guess that adding
more threads to the above test case might make the bug manifest more
often even for localy installed JDK.
###@###.### 1999-07-19 for ###@###.###
There's a race condition introduced in 1.2.2. When a Dialog is
created and its background color is not specified, then under certain
conditions Dialog could inherit background color from its owner
instead of using the system default color (SystemColor.control).
Test case follows.
import java.awt.*;
import java.awt.event.*;
public class Test {
public static void main(String[] args) {
Frame f = new Frame("Frame");
Dialog d = new Dialog(f, "Dialog");
f.setBounds(20, 20, 150, 50);
f.setBackground(Color.yellow);
f.setVisible(true);
d.setBounds(50, 50, 150, 50);
d.setVisible(true); // null bg => should use system default
}
}
If test case is run using installed JDK, the outcome of the race will
almost always be in our favour and the dialog will come up gray, as it
should be. However if JDK is on a remote drive, e.g. NFS mounted
workspace, the it's much easier for the worng thread to win the race
and the dialog will come up yellow (owner's bg). I guess that adding
more threads to the above test case might make the bug manifest more
often even for localy installed JDK.
###@###.### 1999-07-19 for ###@###.###
- backported by
-
JDK-2028144 Regression: Win32: Dialog inherits background from its owner
- Resolved