Hi. Does somebody have an experience with compose desktop being used from java? Writing new components is not an issue. We are interesting in creating desktop application with Java (educational course, java is required). Since we want to avoid Swing we are exploring other options.

Can you be more specific about the "Java is required" part? Compose code has to be in Kotlin, and then you can embed it (with certain restrictions about layering, popups, etc) in your Swing window.

Ah… so I have a wrong understanding of the compose basis — it still needs swing / awt as a glue?

All Compose for Desktop applications ultimately run within Swing, and use it for the basic windowing functionality (opening, resizing, closing windows, handling keyboard/mouse events, etc.). But Compose lives within that, and uses its own drawing algorithms (Skia) to create layouts and draw things that the user actually sees. So while it is using Swing as the glue for the application, you generally don't need to interact directly with Swing APIs to do most stuff that a basic application would need, and it doesn't look "old" like a typical Java desktop app would. Since it is all running within Java, you are free to write the other non-UI layers of your application using whatever Java libraries/architecture you need.

https://github.com/JetBrains/compose-jb/blob/070a8b1f45ad57aa6a807f2d70143db461d54f77/tutorials/Swing_Integration/README.md has a bit more info on Swing's "part" of it

Regarding the bigger picture.. This is a semi-advanced java course which leads to a development of desktop application (we don’t want to do web since that opens a different can of worms). However one of the main complains from students is that while they appreciate the experience of developing a desktop application, swing is tedious to work with, does not look modern and mainly — they are quite unlikely to develop desktop apps using swing in their future careers.

If your business logic is intended to live on the Java side, you'll be missing a lot of really nice things from Compose

So the idea was to replace swing — or at least the Layouting and component parts of it with something more modern, which could potentially lead to more “future-proof” expereince.

It's kinda a no-man's land to start a brand new project by mixing the old and the new worlds.

Agreed. However changing a course in academia is sometimes slow. I’m allowed evolution, however revolution will get me killed quite fast 🙂

The more you can push to the Compose side of things, the cleaner and the more coherent the whole architecture becomes.

You could even have all your GUI in Compose/Kotlin and your older parts of the model in Java and even make that work seamlessly on desktop and Android. Wouldn’t that be cool?

You won't be able to write a CfD app without Kotlin. It's Kotlin/JVM, so you are still able to interop with Java libraries and the Java stdlib, but Kotlin is required, at least for the UI portion of it. Compose works a whole lot better when your "data layer" is built upon Coroutines and Flows, but you can make it work with that portion of the app in Java. Though for students, I think it would just confuse them more if you taught them multiple languages. So either stick to all-Java and use normal Swing UI stuff, or do everything in Kotlin and keep as much of the content within Compose as you can, to avoid even having to think about Swing

Also to be honest, coroutines and flows might take a bunch of time to "get" right.

Makes sense. Thanks for advice. I will make myself more familiar with compose anyway. However I now don’t think this would be a good idea

If CfD is a no go, and your goal is to move away from Swing but stay in Java, have you looked into JavaFX as an alternative?

Quick fixes: 1. Use FlatLAF to give Swing a more modern look. 2. Use JavaFX (a better API than Swing). Put together a bit of custom CSS first to make it look better out of the box.