RFR: 8359266: Delete the usage of AppContext in the GraphicsDevice

[Alexey Ivanov]

On Tue, 24 Jun 2025 17:34:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> That only affects the case where the second thread tries to read shared data (unrelated to GraphicsDevice) without synchronization, which was written before the first thread called getFullScreenWindow(). If visibility is required, it should be ensured by the caller. Depending on some internal and undocumented lock for that is not a good thing.
>> 
>> It is true… but it affects the fields of the full screen window itself. Doesn't any code path uses the fields of the full screen window after getting an object reference to it?
>
> Window fields may be modified at any time by different threads, such as the EDT, Toolkit thread, or others. Without proper synchronization, this can lead to race conditions. Even in the scenario we discussed where getFullScreenWindow() is called twice a race condition can still occur. For example if the first thread modifies the Window and then calls getFullScreenWindow(), and at the same time, a second thread also calls getFullScreenWindow() and attempts to read the Window's fields, a race may occur if the first thread begins modifying the Window again before its next call to getFullScreenWindow().

Yes, I agree race conditions and memory inconsistencies are still in place, however, the synchronized block brought the state of the full screen object to a fresher state.

I looked through the usages of `getFullScreenWindow()` and couldn't find any usages of full screen window fields, so a `volatile` modifier seems appropriate.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25818#discussion_r2166941317