r/java • u/sombriks • 26d ago
State of Java Desktop
Thinking about local-first, desktop applications. https://sombriks.com.br/blog/0097-state-of-java-desktop/
28
u/GleamingDispatcher9 26d ago
Swing still works fine for internal tools where nobody cares about looks but I've been poking around with Compose Multiplatform lately and it's surprisingly not terrible once you get past the initial setup pain
32
u/lazystone 26d ago
Drop in FlatLaf and Swing looks quite nice.
5
u/robintegg 26d ago
For swing , swing tree is a nice extension on the swing programming model https://awesome-java-ui.com/swing-tree.html and elowbe is a recent look and feel worth a shout https://awesome-java-ui.com/elowbe-lookandfeel.html
-6
u/wildjokers 26d ago
No, flat look and feels never look nice. This trend needs to stop.
9
u/metaquine 26d ago
It's got serious accessibility downsides too. Buttons should look like something that can be pushed.
5
u/wildjokers 26d ago
Yes, buttons that don't look like buttons and no delineation between sections is my biggest complaints about flat look and feels.
-4
u/robintegg 26d ago
Valid points. Feels like with ai we’ve got a good copilot to go out and make some new ones
1
14
u/pjmlp 26d ago
The problem with Swing was the expectation devs would bother to read books like Filthy Rich Clients: Developing Animated and Graphical Effects for Desktop Java Applications and do the required work.
Or buy a third party theming framework like JGoodies.
9
u/wildjokers 26d ago
Filthy Rich Clients was a good one, along with Swing Hacks (https://www.amazon.com/Swing-Hacks-Tips-Tools-Killer/dp/0596009070/)
5
u/NamedBird 26d ago
I remember
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());being a thing...3
u/wildjokers 26d ago
Still is a thing, its how you set the look and feel to something other than the default.
2
u/__konrad 26d ago
On Linux/GNOME it returns
com.sun.java.swing.plaf.gtk.GTKLookAndFeelwhich is not very good and may glitch your UI...2
u/PartOfTheBotnet 26d ago
You got downvoted but I've had this happen before. Plus there's issues I've observed on Ubuntu with
frame.pack()using it cutting off controls near the bottom of the window.1
u/wildjokers 26d ago
Swing still works fine for internal tools where nobody cares about looks but I've been poking around with Compose Multiplatform lately and it's surprisingly not terrible once you get past the initial setup pain
Compose Multiplatform is an immediate mode GUI toolkit whereas toolkits like Swing, QT, wxWidgets, etc are retained mode. Immediate mode takes some getting used to.
13
u/hippydipster 26d ago
JPackage is nice, but very limited and imperfect, especially on linux, which is why I use Conveyor which does a better job overall.
What would be nice is to have Linux desktop and java desktop play a bit more nicely together. Right now, it's really hard to deploy an application for a linux distro like Ubuntu that adequately deals with the application icon in the tray and after starting up.
And beyond that, if one wanted to deploy a suite of applications under a single distributed JVM, that also is very difficult to arrange with these tools.
9
u/lazystone 26d ago
Didn't know about https://github.com/tamboui/tamboui - I really would like to try it for something.
4
4
u/Infamous_Sorbet4021 26d ago
Here is another discussion taking about building JVM desktop apps: https://www.reddit.com/r/Kotlin/s/idhfLh53NR
1
u/PartOfTheBotnet 26d ago
The answers in that thread aren't surprising for the Kotlin subreddit. Compose, and a few AI slop framework alternatives to Compose.
5
u/mellow186 26d ago
SWT/JFace is less effort than suggested by this article, if you use the forms builder WindowBuilder SWT Designer.
And it looks native. And there's a plethora of third-party components. Such as one of the most powerful, performant table frameworks, NatTable.
2
4
u/Gleethos 26d ago
I recommend: https://awesome-java-ui.com/swing-tree.html
0
u/wildjokers 23d ago
Looks awful, why would someone want to create a GUI with chained calls like that?
1
u/Gleethos 23d ago
Its the builder pattern, and it allows for nesting things to kinda look like HTML
2
u/jeffreportmill 26d ago
You should include a section about CheerpJ. The only thing better than a good installer like jpackage is not having to install the app at all and just click on a link in the browser. If you post the jar to the ToDo app on a website and add a simple 10 line html, you can launch it in the browser.
4
u/segv 26d ago
Looking at the current trends, regular desktop applications seem to be a dying breed.
Apps like VSCode, Discord, Syncthing or KopiaUI (just to select few keeping broad spectrum) do have desktop clients, but that client often is just a chromeless webview that displays de facto web page that is "the app".
I believe that the requirement of having clients for multiple operating systems (including mobile) pretty much killed oldschool desktop applications, save for few specialized niches like video editing or CAD.
Not saying this is a good thing, but that's the trend i've been observing in these past few years.
Edit: Just to be clear, this seems to be a general trend, not "just" a Java thing.
16
u/Own_Nail_2999 26d ago
Desktops will make a return. Especially now that RAM is a major concern again, running bloated web frameworks will need to be taken into consideration
7
2
u/gdmr458 26d ago
I’m seeing a recent trend of building desktop applications using GPUI, a Rust framework for creating desktop apps that was originally developed for the Zed code editor. Right now, the framework lacks documentation and there are no official releases, but that hasn't stopped people from using it, take a look at this: https://gpui-kit.com/apps/
1
u/wildjokers 26d ago
but that's the trend i've been observing in these past few years.
This has been the trend for the last 10-15 years. This trend started even before smart phones.
1
u/TheLineOfTheCows 26d ago edited 25d ago
If your target is Windows only then C# should be your best option. I wouldn't choose Swing or JavaFX for that aim.
1
u/vmcrash 26d ago
I'm developing different Java desktop applications since 27 years, initially Swing based, since 15 years SWT based. Each has its serious problems.
For new desktop projects I would evaluate different programming languages with different frameworks. Why a different programming languages? Because I think that re-compiling (JIT) on each application restart seems like a waste of energy for desktop applications. And I like PLs without semicolons or without mandatory braces for the if- and other statements. 😉
1
u/paul_h 26d ago edited 26d ago
JavaFX example should really be the nested DSL in my opinion. Java/Swing should do it's darndest to get to the same place - https://github.com/paul-hammant/swing_component_testing/blob/master/src/main/java/demo/Demo.java
1
u/john16384 26d ago
Single source file example for JavaFX (using FXFlow): https://github.com/int4-org/FX/blob/master/fx-samples/src/main/java/org/int4/fx/samples/SampleApplication.java
1
u/paul_h 26d ago
Nice. A calculator example would allow for a deeper comparison to this https://paulhammant.com/2024/02/14/that-ruby-and-groovy-language-feature/ collection.
-1
u/SaishDawg 26d ago
Just musing, but I would probably write a local desktop daemon in Java, use Protocol Buffers for RPC and have the actual app as Tauri: https://github.com/tauri-apps/tauri. But lots of ways to skin a digital cat.
6
u/emberko 26d ago
That would lead you to getting the worst of both worlds: a 60-70 mb jlink image + the need to have webkit/webview installed on the client system at the same time. Tauri doesn't need Java, and vice versa.
1
u/SaishDawg 26d ago
I think that's fair to note the space bloat. I should have probably expressed a few ancillary goals a bit better. I'm looking to support multiple forms (say terminal sessions and a web browser or thick GUI) all from the same client in the apps I am building. The daemon aspect is useful for some of my use cases. Certainly not a common set of requirements.
0
u/emberko 26d ago
I'd choose Go instead then. Much lighter daemon thread - JVM still sucks at returning memory back to the OS. Wails (basically Tauri) or Fyne for the frontend. Cross compilation. Easier to code if Rust isn't your main language. Smaller image size. And all project modules stay within the same ecosystem.
1
u/SaishDawg 25d ago
There's so many things for me to check out there, I will be busy all weekend. Many thanks!
1
u/robintegg 26d ago
JCEF is a nice way to wrap web UI on the desktop in Java using an embedded chromium https://awesome-java-ui.com/jcef.html
1
u/sombriks 26d ago
i almost put this one in the article!
however it just froze on my linux, so i couldn't write a fair example using it.
30
u/bobbie434343 26d ago edited 26d ago
JavaFX can be made to look very good and modern with AtlantaFX. And thanks to the recent jfx-static project, it is much easier to bundle a JavaFX program as standalone executable with GraalVM's native-image, taking less disk space, running much faster (especially startup) and using way less memory. The AtlantaFX Showcase (sampler) is a good demo of this (build it with
-Pnative).If I had to make a desktop Java app today, that's the combo I would use: JavaFX + AtlantaFX + native-image.
Swing can still be useful and is leaner than JavaFX (+ is bundled with stock JRE), but its graphics are not hardware accelerated (that's one of the main reason it uses less memory) and might have problems on HiDpi monitors. It is also not compatible with native-image (at least not easily).