Hello, Now that applets are deprecated for removal, what do you think about moving towards the unification of event dispatch and toolkit threads in AWT? In my understanding, thе separation between them was meaningful only for the applet use case, and now it becomes a pure nuisance. E.g. accessibility support implementation on macOS requires 'invokeAndWait' calls between two threads in both directions, and achieving this without deadlocks is quite tricky in current implementation. Also, windowing APIs on macOS and Windows are mostly synchronous, and using them in a synchronous way (without passing execution between threads) could potentially simplify focus subsystem implementation. Benefits for X11/Wayland systems would be less significant, due to the fundamentally asynchronous native APIs, but, even in those cases, having both outgoing requests sending and incoming events processing on the same thread should make AWT code more reliable, as we'll have one less place for potential races.
Overall, having only one thread to deal with native windowing APIs, should make supporting and extending AWT simpler, and closer to native application development. I think, some synchronization constructs would still need to be present - to guard against the invocation of AWT methods from background threads. But, at least for 'well-behaving' apps, the reasoning about execution order would be much easier. Of course, for existing toolkit implementations (macOS/Windows/X11) the transitioning will take some time and effort, but for the Wayland implementation, to be developed withing Wakefield project, the idea could be implemented from start. AFAIU, with Wayland client API, we'll need to dispatch the incoming queue of events explicitly anyway, and this dispatching can quite as well be done on EDT. So, what do you think about the idea in general, and about starting to realize it in Wayland toolkit implementation? Best regards, Dmitry Batrak
