Details
-
Bug
-
Resolution: Unresolved
-
P3
-
8u162, 16, 17
-
os_x
Description
A common way to create a window is to perform a sequence of operations:
1. create window
2. use pack to set the window size
3. set the window location
4. set the window to visible
For example, this is what happens when creating a dialog using JFileChooser, which is where I encountered the problem.
On macOS, there is a race condition in which step 3 reverts the effect of step 2, resulting in the window being displayed with a minimum size. Because the problem is a race condition, it may occur intermittently and only on certain systems. It might require a system with enough cores to allow the AWT and main threads to execute simultaneously.
The problem can be demonstrated using the enclosed test program, which uses a breakpoint to introduce a delay into internal AWT code. The bug is repeatable on my system (an iMac with 8 cores), but may not happen at all on other systems.
The cause of the problem is clear. After AWT sets the bounds of a native window, at some later time there is an upcall from AppKit on the main thread that announces the bounds change. The response by AWT is to directly set the width and height fields in the Window to the values in the reported bounds. There is no synchronization with the AWT thread at all. If AWT has performed two bounds changes and the first upcall arrives after the second change, then it will (temporarily) revert the field values to the values set in the first bounds change. This is the cause of the bug.
Specifically, the bug occurs when these events happen in this order:
1. When a new window is created, the native window is first created and then its bounds are set to a minimum size. (Upcall #1 is now pending.)
2. Pack calculates the preferred size and changes the window bounds. This operation first updates the size fields, then sets the bounds of the native window. (Upcall #2 is now pending.)
3. The upcall from the first native bounds change arrives. The size fields in the window are set to the minimum size.
4. setLocation reads the size fields to create new bounds with a new location and the existing (but incorrect) size. The native window bounds are updated with the incorrect size. (Upcall #3 is now pending.)
1. create window
2. use pack to set the window size
3. set the window location
4. set the window to visible
For example, this is what happens when creating a dialog using JFileChooser, which is where I encountered the problem.
On macOS, there is a race condition in which step 3 reverts the effect of step 2, resulting in the window being displayed with a minimum size. Because the problem is a race condition, it may occur intermittently and only on certain systems. It might require a system with enough cores to allow the AWT and main threads to execute simultaneously.
The problem can be demonstrated using the enclosed test program, which uses a breakpoint to introduce a delay into internal AWT code. The bug is repeatable on my system (an iMac with 8 cores), but may not happen at all on other systems.
The cause of the problem is clear. After AWT sets the bounds of a native window, at some later time there is an upcall from AppKit on the main thread that announces the bounds change. The response by AWT is to directly set the width and height fields in the Window to the values in the reported bounds. There is no synchronization with the AWT thread at all. If AWT has performed two bounds changes and the first upcall arrives after the second change, then it will (temporarily) revert the field values to the values set in the first bounds change. This is the cause of the bug.
Specifically, the bug occurs when these events happen in this order:
1. When a new window is created, the native window is first created and then its bounds are set to a minimum size. (Upcall #1 is now pending.)
2. Pack calculates the preferred size and changes the window bounds. This operation first updates the size fields, then sets the bounds of the native window. (Upcall #2 is now pending.)
3. The upcall from the first native bounds change arrives. The size fields in the window are set to the minimum size.
4. setLocation reads the size fields to create new bounds with a new location and the existing (but incorrect) size. The native window bounds are updated with the incorrect size. (Upcall #3 is now pending.)
