Round 1: AWT. Uses the native widgets. Therefore the layout is slightly different on different platforms.
Round 2: Swing. Cross-platform identical, and therefore looks nothing like native apps. You could 'skin' it, at which point it would look native but behave subtly differently.
Round 3: SWT. Back to native widgets for Eclipse.
Round 4: Everyone throws up their hands in despair and stops writing desktop applications.
Indeed. If cross-platform UI toolkits have shown us anything, it's that cross-platform UI toolkits are a bad idea.
You end up targeting the lowest common denominator, and a UI convention that works on Windows won't work on OS X, and vice versa.
One big error made by these toolkits is to base themselves on generic pixel-oriented layouts, instead of more abstract declarative ones. For example, if you need a dialog box with a small form and "OK" and "Cancel" buttons, you'd lay each component out on a form, and the layout would be identical on each platform. But this is such a common thing to do that it would be better to just declare what fields should be visible and what actions should be available, and have different, platform-specific, opinionated adapters that can wire together a native UI from this metadata (together with some platfomr-specific, CSS-like hinting: "on OS X this field needs to be at least 500px wide", etc.).
There's a wide selection of common idioms (dialog boxes, file dialogs, "wizards", preference panes, alerts, etc.) that fit into this scheme. The reason nobody did this is probably because developers overestimate how important it is to micromanage the UI, and don't think a system like this could support all variations that apps need. In truth, most UIs are quite pedestrian, and could benefit from being driven by a high-level description.
This is where React (and React Native) actually would help, because the component interface is separate from the component implementation. You can have a fairly high-level mostly-declarative description of your app that pulls in platform-specific versions of certain UI widgets where it makes sense to have one, but otherwise relies on generic ones.
Java was captured by "Enterprise", lending it an air of radioactive uncoolness. So people are very reluctant to look at it and risk learning something from its successes and failures.
Came here to say this. For quite a few years in the bad old days around Y2K, people thought they would get a free cross-platform lunch by writing GUI applications in Java. This wasn't so bad in Xwindows, where every program did its own thing already, but it was terrible everywhere else. It took years for developers to get it, and there are probably still a few internal corporate applications using Java; I suspect the same will happen over the next 5-10 years with JS.
I think part of the reason that it might be different this time round is because using web technologies for desktop applications gives access to a much broader pool of UI/UX talent to help build something that works well and looks nice. Applications built with web technologies are already looking noticeably better than anything you get with a cross-platform UI toolkit without putting in a lot of effort.
Round 1: AWT. Uses the native widgets. Therefore the layout is slightly different on different platforms.
Round 2: Swing. Cross-platform identical, and therefore looks nothing like native apps. You could 'skin' it, at which point it would look native but behave subtly differently.
Round 3: SWT. Back to native widgets for Eclipse.
Round 4: Everyone throws up their hands in despair and stops writing desktop applications.