JDK-8270211 : Find a better solution for the undocumented special Java AppKit thread run loop mode.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 11,17
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: os_x
  • Submitted: 2021-07-09
  • Updated: 2024-01-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8274596 - [macos] supporting JavaNativeFoundation use by libraries and applications
Relates :  
JDK-8270216 - [macOS] Update named used for Java run loop mode
Relates :  
JDK-8221261 - Deadlock on macOS in JFXPanel app when handling IME calls
Description
On macOS, when AWT enters a nested event loop and it wants to have only related messages
processed by that  secondary loop it specifies that the current NSRunLoop should enter a
special named mode. It also includes this name in the list of modes used when scheduling
a selector to run so that it matches the current run loop.

This means that any code that wants to run on the AppKit thread whilst this mode is in effect also needs to specify this mode.

Since the intention is to block code not specifying that mode, this could be seen as reasonable.

The present problem is that the deprecated JNF library would add this run loop mode to any call made
using its utility APIs to run on the main thread. So if any code used this whilst Java is in this nested
mode it would still run.

The run loop mode is just an NSString but there needs to be either a supportable, documented,
shared (at runtime) way of finding out what it is, *or* JDK needs to stop specifing that special mode.

Documenting it isn't particularly desirable since it also implies a lot about the JDK implementation
which goes beyond what we would ordinarily do, more so than other JAWT type interfaces.
On the other hand dispensing with the mode is obviously not risk free and there may be some
technical obstacle to it and will require substantial bake time

So this bug will be used to investigate these alternatives, and perhaps other, and choose.
Comments
The third option (besides documenting the name or stopping using the name) is to provide a native API that does what JNFRunLoop does. That would seem to address your concerns and it is a trivial solution. The current solution addresses problems that arise when Java code related to the Java UI needs to access native UI functionality. That creates a situation where the AWT event thread needs to perform code on the AppKit main thread while waiting for the completion of that code. I don't think you want to rule out this possibility. It is not possible to predict when AWT will need to service an AppKit request, as these requests can arise from user actions, such as using a keyboard shortcut or resizing a window, so deadlock is not something that the application developer can easily avoid. A more satisfying, but much more challenging solution, would be to rearchitect AWT so that it can service all requests from AppKit without needing to run any code on the AWT event thread. That sounds like a high risk solution, because it probably would need to add synchronization internal to AWT/Swing.
13-07-2021