Eh, maybe. Familiarity breeds contempt. I think they feel like they're sort of out on their own with Swing and the cool kids are moving on to new things. They l

Eh, maybe. Familiarity breeds contempt. I think they feel like they're sort of out on their own with Swing and the cool kids are moving on to new things. They like the DSL aspect of Compose. Could the advantages of Compose be brought to Swing - probably. My guess is yes. But if Google are planning to spend the next decade heavily investing in a Kotlin-first toolkit and millions of Android devs will learn it, you can see how they arrived at the decision to go the whole way. AWT actually uses native widgets, so if your needs are simple it's one of the fastest ways to go as the code is all loaded in memory already and written in C/C++, it's a part of the OS after all. Modern Swing isn't slow. IntelliJ's performance isn't limited by Swing I think, it's much more limited by RAM in general. JavaFX never reached the maturity of Swing in terms of raw stability, but it's got a drastically better API and TornadoFX shows you can layer a Kotlin DSL on top very easily. Frankly I wish they were investing in JavaFX instead because it's actually a desktop toolkit, and is already "there", whereas Compose is going to be beta-ware for a long time. JavaFX has been stabilising over time because for the last 7 years or so it's not been adding many features, the work has all been bug fixing and performance improvements. It's a mature toolkit that just didn't quite get critical mass.