I agree with your comment. Every UI framework I have used (AppKit, Swing, JavaFX, etc.) is not thread-safe. It requires all UI code in the main thread or, in the case of JavaFX, a dedicated UI thread (not necessarily the main thread, but it must be a single thread where all UI operations occur).

WPF was the same IIRC

yup!

That's how winforms did it; and I suspect that's how the underlying Windows OS needs it done too.

Technically in JavaFX you can work with UI objects off the main thread, for instance to load or build up UI in parallel. The single thread requirement only kicks in when UI is attached to a live window (stage).

IBM made a similar decision before the larger Java community thought it was anything like a good idea.

Even outside of UI, use-from-one-thread-only is perfectly valid and acceptable. The issue at that point is with the tools (e.g. C), not the API. If the API provides thread-safe entry points, that's because it is taking on the responsibility of synchronizing. Maybe that's fine for a particular API, but it shouldn't be expected for everything. It's an added layer of complexity, hidden from the programmer, so expect it to be absent in more optimized cases.