* The first time any particular window is opened, Swing draws the contents but then changes its mind about the window size, recalculates the layout and then redraws the contents again slightly differently.
* When Swing creates a window, you can sometimes observe how creates it in the wrong spot and then moves it to where it was supposed to be created.
* Alt-tabbing quickly between two windows in a Swing application doesn't always work. It sometimes just glitches and leaves you in the window you started with. (Confirmed just now on Windows 10 with Java 17. The bug has been there for many, many years.)
* When opening a submenu of a menu, Swing does nothing to handle the problem of the menu closing again as you're moving towards it but accidentally mouse over an adjacent item. Platform GUI toolkits solve this either with a delay or by tracking the direction of the movement. IntelliJ implements its own menu bar to make this work.
* Try to find an example of a window that is resizable in only one direction or only up to a certain maximum size. As far as I can tell, this is not possible in Swing, and applications handle this limitation by designing all UIs to be resizable even when it doesn't make any sense.
First of all, up-to-date official packages are now published to Maven Central as part of the release process, so you can just add it as a dependency as easily as with any other library. Until recently you would have had to either fiddle around with Eclipse's alternative package management system, download it manually or use someone's unofficial Maven artifact. But that's now resolved.
Secondly, if you bundle a Java runtime customized with jlink (as is recommended these days), an SWT application is actually smaller than a Swing application. When you don't use Swing, you can exclude the entire "java.desktop" module, which is slightly larger than the SWT libraries.
It looks mostly ok, but on Linux it doesn’t support smooth scrolling (even though this is supported by gtk). You also can’t use the meta key (windows key / cmd) as a modifier key for keyboard shortcuts. So I can’t configure intellij to use all the keyboard bindings I’m used to from macos. Again, this isn’t a problem with other gtk apps. It’s just (apparently) a platform limitation of whatever Java toolkit they’re using.
So in my experience it’s 95% of the way there. I certainly prefer it over Xcode, but it has issues that native apps don’t have.
It's amazing the amount of work JetBrains has put into this.
And there are non-native behaviors in IntelliJ too. For example you can’t close windows by double-clicking the window icon on Windows (a feature of Windows since Windows 1?).