9 ms·

The effort is laudable, but ultimately futile. The world has moved on from Java on the client. It is now largely relegated to a backend language for enterprise

The effort is laudable, but ultimately futile. The world has moved on from Java on the client. It is now largely relegated to a backend language for enterprise applications. Nobody really wants the heavyweight mess that is the JRE on the desktop when other frameworks do a better job. There was a case for Java-based desktop apps in the 1990s/2000s when browsers were slow, desktop UI toolkits were generally terrible and lacked cross-platform capabilities. But this was then and now is now. So no, a new UI toolkit is not going to revive Java in the mainstream.

lumost 5y ago
Aren't android UIs predominantly Java?
- DaiPlusPlus 5y ago
  Android's "native" UI library has hard dependencies on key components of the Android OS that go far beyond what can be provided by any random Java JVM/JRE (i.e. you can't simply use Android's UI .jars almost anywhere like we can with AWT and Swing). Saying "Android's UI is Java" is like saying "Apple's macOS Cocoa is x86" - technically true, but belies the sheer volume of transitive dependencies.
  - mike_hearn 5y ago
    That's true of classic Android UI, which isn't that great anyway. The new JetPack Compose ui toolkit is cleanly abstracted from Android and works on the desktop as well.
- datavirtue 5y ago
  Yeah, as are some of the most popular and modernized desktop apps. I'm always astounded by these posts. Java has two modern UI frameworks. Swing and JFX. They blow Microsoft's offerings out of the water--while being proven cross-platform.
  - DaiPlusPlus 5y ago
    > Java has two modern UI frameworks. Swing and JFX. They blow Microsoft's offerings out of the water--while being proven cross-platform. I hope you're being sarcastic there... Swing is decidedly not "modern" at all: its active development period only lasted from 1998 ended by 2005, and saying that Swing is "cross platform" is really overselling it because it always looks out-of-place, if not downright hideous (default skin) on every platform; While JavaFX is/was so unpopular that it was removed from Java SE and Oracle will stop supporting it by 2025.
    - kaba0 5y ago
      Regarding the microsoft part, how can anything not look out-of-place, when their own settings appS have like 5 different GUI design here and there. Otherwise, JavaFX was axed from the JDK because there is absolutely no reason to tie a frontend lib’s lifecycle to that of the JDK’s. Swing could not be axed due to the insane amount of dependencies on it, but JavaFX has it in a way, better as being developed separately. And even though it is not huge in terms of marketshare, it is doing good with proprietary solutions, cross-platform compilation to web, desktops, and both android and ios being available.
  - luciusdomitius 5y ago
    Well, which ones. I use IntelliJ and SQL Developer. While the first one is one of the best tools in the toolbox, it still has problems with global menus, dpi and pretty much everything very platform specific. Using xfce probably doesn't help. Truth is that the only advantage Desktop Java has over electron is that it is a bit faster and less leaky, but the advantage above Qt is only that you don't need to learn C++.
luciusdomitius 5y ago
I agree with the conclusion, but not with the argumentation, which would factologically correct sometime around 2012. For example these days you have modular JVM, GraalVM, etc and a hello world Micronaut service launches for about 20ms. This doesn't affect the uselessness of client java as competition has also improved and java doesn't offer anything extra. If you want it quick & dirty you use electron, if you want to have it nice & smooth - QT. Desktop Java is neither a fish, nor a crab in a way.
- kaba0 5y ago
  How is Java desktop not nice & smooth?
hwers 5y ago
This is such a US worldview. As someone from europe, I'm still scared I'll stumble into a job where needing to code Java sneaks up on me (and quitting with leave and finding a new job is a few months endeavor). I wish it wasn't used anymore but that's far from the actual truth.
- eddieroger 5y ago
  American here. The way I read that argument was Java on the desktop for UIs, not "no Java anywhere." Java has been a core part of every company I've worked for since finishing school, it's just kept on the backend in the service of APIs and the like. But other than Android UIs, mentioned in a different reply, Java isn't the driver of desktop applications, and probably won't be in the presence of Electron apps and more movement to mobile anyway.
- nikanj 5y ago
  Why do you wish it wasn't used anymore?
- KptMarchewa 5y ago
  Code Java or code desktop Java? You can easily stumble on stuff like Spring every job, but I'd be very surprised if I started new job and it turned out I have to write JavaFX as part of it.
matsemann 5y ago
All your points tell you haven't a clue of how modern java works. No need to mess with the JRE, just bundle whatever you need in your executable and it behaves just like any other application. And it's not heavyweight, at least not compared to Electron and friends, which are thriving. So I don't see why that should be a concern.
- towndrunk 5y ago
  Can you point to an example? I would love to download one of these types of apps and give it a try.
  - ericd 5y ago
    I think Slay the Spire is written in Java? At least there’s a mention of it on the launcher.
  - yashap 5y ago
    IntelliJ IDEA is the first that springs to mind - very popular Java app that ships with a bundled JRE. Not sure I’d call it “lightweight”, it does take awhile to boot up, but once it boots it’s a great app.
    - nicoburns 5y ago
      > Not sure I’d call it “lightweight” Indeed, I'd argue that apps like IntelliJ are exactly why nobody wants Java on the Desktop. I had to buy a computer with more RAM specifically because IntelliJ uses so much. Even Electron apps aren't so bad with regard to RAM usage.
      - perrylaj 5y ago
        This might be true, but it's also misleading. Intellij is a pretty huge application, with a gigantic set of features and capabilities, likely far more substantial than even the largest/most complex Electron app out there. Intellij would require notable memory and cpu regardless of whether or not it was Java. See XCode and Visual Studio for comparison, as they are probably closer to the same feature profile than something like VSCode would be. Their memory footprint and performance is not what I'd call substantially better than Intellij (and as with most comparisons of this nature, many caveats exist around which plugins/addons/features are in use). Would Intellij have a better resource profile if it were native? Ya, possibly, but it's also possible that another language/platform would have been a significant barrier to long-term success. Not many cross-platform UI toolkits from 2000 to choose from, and many fewer have continued to be well-maintained and usable today.
islon 5y ago
Devs complaining that the JVM is too heavyweight for client applications when electron is dominating the desktop landscape. Satire is dead...
- blablabla123 5y ago
  That's true on the other hand the state of Java desktop UI frameworks is at best confusing. I guess it's possible to write well performing Java desktop apps and yet I have a Java app that slows down my whole system and usually crashes on macOS
  - mixmastamyk 5y ago
    I use DBeaver on MacOS and it is pretty good and responsive. Only one intermittent keybinding bug with home/end.
  - johntdaly 5y ago
    Is the App an old POS? I see a lot of old Java Apps still around that sort of bitrotted to hell. We bitched so much about Java Apps that so many just got abandoned, even if the apps where sort of cool and/or didn’t have a replacement. Maybe I’m getting old but I’m a bit sad for all the open source apps that where abandoned over the years because the tech stack stopped being cool.
    - kaba0 5y ago
      Anecdotal, but Java is the only platform where I could download a random jar from a possibly long dead professor’s abandoned website and have a working GUI of some CS algorithm visualization with a double-click. Hell, websites don’t hold up as well to time with all the missing links/resources.
  - thfuran 5y ago
    It's much easier to write an application that crashes in C++ than in Java. I don't think the existence of whatever program you're talking about demonstrates much.
- 5y ago
rsynnott 5y ago
> Nobody really wants the heavyweight mess that is the JRE on the desktop I mean, people seem to put up with electron these days, and the few modern JVM GUI apps feel generally better than electron stuff (for instance the all-pervasive UI latency that you get with things like vscode and slack is largely absent from IntelliJ).
- kizer 5y ago
  That latency really is the killer. The web needs a fast UI layer separate from the DOM. I’m waiting for WebGPU to roll out and build a UI library on top of it, forgoing the DOM. But then this is just another “hack”. I wish the web had something a bit better.
  - zozbot234 5y ago
    The DOM can be blazing fast. Just avoid pointless div soup, and use CSS that avoids complex text reflowing when not strictly necessary.
topaz0 5y ago
The world is very large. Possibly most of it has moved on from Java, but I am frequently surprised by how often I encounter it in scientific applications. For example, ImageJ and micro-manager are very important players in the microscopy world, both large UI-heavy java projects, and MATLAB's UI is java based.
- thfuran 5y ago
  Isn't matlab's everything java-based?
  - topaz0 5y ago
    I'm not sure... you can run it with a -nojvm flag, which turns off the ui but still gives you an interpreter, but I'm not sure if that means "no java at all" or something more specific.
TeaVMFan 5y ago
SnapKit lets you code in Java but deploy as transpiled JS when using SnapTea. No JRE, just a native browser app. Try the demos, it is quite, well, snappy.
Macha 5y ago
Even the one platform where Java is the native language of the UI toolkit (Android) is moving to ditch the Java language for Kotlin.
- AtlasBarfed 5y ago
  Kotlin doesn't bundle a fundamentally new/better UI toolkit. It's just another JVM language. Most complaints about UI toolkit in "Java" are really about the JDK, its startup time, and the fact that the UI toolkit in the AWT/Swing days never closed the gap with native apps. Kotlin would just be using the core library UI (or android UI API), so it's no real advantage.
- la_fayette 5y ago
  Yes true, but the android sdk is completely written in java and this most likely will stay like this. Even some new jetpack libraries are written in java... If a newer java version would be enabled for android development, is there really a compelling reason to use kotlin?
- kaba0 5y ago
  Android’s Java is no real java, it is stuck in a strange limbo of Java 8 compatibility with some cherry-picking from fresher features, while actual Java is at 18 now with plenty of important improvements. Kotlin compiles some of these newer features’ equivalents to java 8, that’s why it is used. But that is a failure of android, not of Java.
mattbrewsbytes 5y ago
I think you could just say the world has moved on from client-side desktop apps. Doesn't matter much what language, the majority of applications are web-based and there are major negatives to having a client side install experience with patching, versioning, support, etc. Yes there are still niche domains that would need a desktop app but those are probably more rare as time goes on and/or already have established players.
- mike_hearn 5y ago
  Client side install experience is what mobile apps have, and everyone seems to prefer them to web apps. Web apps also have major downsides. It's easy to forget about them as developers, but for example, one is the lack of versioning. Someone pushes a new version of the app that's buggy/an UI downgrade/causes an outage and the users can't do anything about it. Often you want an app to be local because it's interacting with local data, or local hardware, or it suffers from latency, or you don't want your data to go outside your jurisdiction, or it's doing something else where distance between you and the app is problematic. Client side apps written using normal toolkits (not HTML) have a lot of major end user advantages, which is why: • Mobile apps beat web apps, despite devs trying to make users accept them (recall the history of the Facebook app for example). • HTML5 keeps sprouting features that desktop apps have had since the beginning. Filesystem access is a recent example. Any time you want your data to be independent of the apps that work with it, web apps just faceplant. In my view developers push web apps on users usually for our own convenience, e.g. being easier to bypass IT department bureaucracy. But there's a lot of ways to do better than web apps, and yes, the JVM is pretty good platform to do that on (JavaFX is a great toolkit for instance, and JetPack Compose is very interesting). What it needs is a great distribution and update solution.
  - mattbrewsbytes 5y ago
    I was mostly referring to desktop app vs. web app since the OP was talking about desktop apps. Mobile apps are a different topic but they also share a set of the similar trade-offs of a desktop app with install/upgrade and support (i.e. multiple devices/versions). Pushing buggy/UI problematic software is a process/people problem not really a technology problem. I would bet the feedback loop for getting fixes in on web apps can be much shorter than client desktop apps (or mobile). Once a fix/change is tested we can have it out in production on a web app for 100% of users in 20 minutes. Stand-alone apps are a great niche where the native UI kit or other UI kits that work for the problem being solved are a great solution, there isn't a need for web tooling.

lumost 5y ago

Aren't android UIs predominantly Java?

DaiPlusPlus 5y ago
Android's "native" UI library has hard dependencies on key components of the Android OS that go far beyond what can be provided by any random Java JVM/JRE (i.e. you can't simply use Android's UI .jars almost anywhere like we can with AWT and Swing). Saying "Android's UI is Java" is like saying "Apple's macOS Cocoa is x86" - technically true, but belies the sheer volume of transitive dependencies.
- mike_hearn 5y ago
  That's true of classic Android UI, which isn't that great anyway. The new JetPack Compose ui toolkit is cleanly abstracted from Android and works on the desktop as well.
datavirtue 5y ago
Yeah, as are some of the most popular and modernized desktop apps. I'm always astounded by these posts. Java has two modern UI frameworks. Swing and JFX. They blow Microsoft's offerings out of the water--while being proven cross-platform.
- DaiPlusPlus 5y ago
  > Java has two modern UI frameworks. Swing and JFX. They blow Microsoft's offerings out of the water--while being proven cross-platform. I hope you're being sarcastic there... Swing is decidedly not "modern" at all: its active development period only lasted from 1998 ended by 2005, and saying that Swing is "cross platform" is really overselling it because it always looks out-of-place, if not downright hideous (default skin) on every platform; While JavaFX is/was so unpopular that it was removed from Java SE and Oracle will stop supporting it by 2025.
  - kaba0 5y ago
    Regarding the microsoft part, how can anything not look out-of-place, when their own settings appS have like 5 different GUI design here and there. Otherwise, JavaFX was axed from the JDK because there is absolutely no reason to tie a frontend lib’s lifecycle to that of the JDK’s. Swing could not be axed due to the insane amount of dependencies on it, but JavaFX has it in a way, better as being developed separately. And even though it is not huge in terms of marketshare, it is doing good with proprietary solutions, cross-platform compilation to web, desktops, and both android and ios being available.
- luciusdomitius 5y ago
  Well, which ones. I use IntelliJ and SQL Developer. While the first one is one of the best tools in the toolbox, it still has problems with global menus, dpi and pretty much everything very platform specific. Using xfce probably doesn't help. Truth is that the only advantage Desktop Java has over electron is that it is a bit faster and less leaky, but the advantage above Qt is only that you don't need to learn C++.

luciusdomitius 5y ago

I agree with the conclusion, but not with the argumentation, which would factologically correct sometime around 2012. For example these days you have modular JVM, GraalVM, etc and a hello world Micronaut service launches for about 20ms. This doesn't affect the uselessness of client java as competition has also improved and java doesn't offer anything extra. If you want it quick & dirty you use electron, if you want to have it nice & smooth - QT. Desktop Java is neither a fish, nor a crab in a way.

kaba0 5y ago
How is Java desktop not nice & smooth?

hwers 5y ago

This is such a US worldview. As someone from europe, I'm still scared I'll stumble into a job where needing to code Java sneaks up on me (and quitting with leave and finding a new job is a few months endeavor). I wish it wasn't used anymore but that's far from the actual truth.

eddieroger 5y ago
American here. The way I read that argument was Java on the desktop for UIs, not "no Java anywhere." Java has been a core part of every company I've worked for since finishing school, it's just kept on the backend in the service of APIs and the like. But other than Android UIs, mentioned in a different reply, Java isn't the driver of desktop applications, and probably won't be in the presence of Electron apps and more movement to mobile anyway.
nikanj 5y ago
Why do you wish it wasn't used anymore?
KptMarchewa 5y ago
Code Java or code desktop Java? You can easily stumble on stuff like Spring every job, but I'd be very surprised if I started new job and it turned out I have to write JavaFX as part of it.

matsemann 5y ago

All your points tell you haven't a clue of how modern java works. No need to mess with the JRE, just bundle whatever you need in your executable and it behaves just like any other application. And it's not heavyweight, at least not compared to Electron and friends, which are thriving. So I don't see why that should be a concern.

towndrunk 5y ago
Can you point to an example? I would love to download one of these types of apps and give it a try.
- ericd 5y ago
  I think Slay the Spire is written in Java? At least there’s a mention of it on the launcher.
- yashap 5y ago
  IntelliJ IDEA is the first that springs to mind - very popular Java app that ships with a bundled JRE. Not sure I’d call it “lightweight”, it does take awhile to boot up, but once it boots it’s a great app.
  - nicoburns 5y ago
    > Not sure I’d call it “lightweight” Indeed, I'd argue that apps like IntelliJ are exactly why nobody wants Java on the Desktop. I had to buy a computer with more RAM specifically because IntelliJ uses so much. Even Electron apps aren't so bad with regard to RAM usage.
    - perrylaj 5y ago
      This might be true, but it's also misleading. Intellij is a pretty huge application, with a gigantic set of features and capabilities, likely far more substantial than even the largest/most complex Electron app out there. Intellij would require notable memory and cpu regardless of whether or not it was Java. See XCode and Visual Studio for comparison, as they are probably closer to the same feature profile than something like VSCode would be. Their memory footprint and performance is not what I'd call substantially better than Intellij (and as with most comparisons of this nature, many caveats exist around which plugins/addons/features are in use). Would Intellij have a better resource profile if it were native? Ya, possibly, but it's also possible that another language/platform would have been a significant barrier to long-term success. Not many cross-platform UI toolkits from 2000 to choose from, and many fewer have continued to be well-maintained and usable today.

islon 5y ago

Devs complaining that the JVM is too heavyweight for client applications when electron is dominating the desktop landscape. Satire is dead...

blablabla123 5y ago
That's true on the other hand the state of Java desktop UI frameworks is at best confusing. I guess it's possible to write well performing Java desktop apps and yet I have a Java app that slows down my whole system and usually crashes on macOS
- mixmastamyk 5y ago
  I use DBeaver on MacOS and it is pretty good and responsive. Only one intermittent keybinding bug with home/end.
- johntdaly 5y ago
  Is the App an old POS? I see a lot of old Java Apps still around that sort of bitrotted to hell. We bitched so much about Java Apps that so many just got abandoned, even if the apps where sort of cool and/or didn’t have a replacement. Maybe I’m getting old but I’m a bit sad for all the open source apps that where abandoned over the years because the tech stack stopped being cool.
  - kaba0 5y ago
    Anecdotal, but Java is the only platform where I could download a random jar from a possibly long dead professor’s abandoned website and have a working GUI of some CS algorithm visualization with a double-click. Hell, websites don’t hold up as well to time with all the missing links/resources.
- thfuran 5y ago
  It's much easier to write an application that crashes in C++ than in Java. I don't think the existence of whatever program you're talking about demonstrates much.
5y ago

rsynnott 5y ago

> Nobody really wants the heavyweight mess that is the JRE on the desktop I mean, people seem to put up with electron these days, and the few modern JVM GUI apps feel generally better than electron stuff (for instance the all-pervasive UI latency that you get with things like vscode and slack is largely absent from IntelliJ).

kizer 5y ago
That latency really is the killer. The web needs a fast UI layer separate from the DOM. I’m waiting for WebGPU to roll out and build a UI library on top of it, forgoing the DOM. But then this is just another “hack”. I wish the web had something a bit better.
- zozbot234 5y ago
  The DOM can be blazing fast. Just avoid pointless div soup, and use CSS that avoids complex text reflowing when not strictly necessary.

topaz0 5y ago

The world is very large. Possibly most of it has moved on from Java, but I am frequently surprised by how often I encounter it in scientific applications. For example, ImageJ and micro-manager are very important players in the microscopy world, both large UI-heavy java projects, and MATLAB's UI is java based.

thfuran 5y ago
Isn't matlab's everything java-based?
- topaz0 5y ago
  I'm not sure... you can run it with a -nojvm flag, which turns off the ui but still gives you an interpreter, but I'm not sure if that means "no java at all" or something more specific.

TeaVMFan 5y ago

SnapKit lets you code in Java but deploy as transpiled JS when using SnapTea. No JRE, just a native browser app. Try the demos, it is quite, well, snappy.

Macha 5y ago

Even the one platform where Java is the native language of the UI toolkit (Android) is moving to ditch the Java language for Kotlin.

AtlasBarfed 5y ago
Kotlin doesn't bundle a fundamentally new/better UI toolkit. It's just another JVM language. Most complaints about UI toolkit in "Java" are really about the JDK, its startup time, and the fact that the UI toolkit in the AWT/Swing days never closed the gap with native apps. Kotlin would just be using the core library UI (or android UI API), so it's no real advantage.
la_fayette 5y ago
Yes true, but the android sdk is completely written in java and this most likely will stay like this. Even some new jetpack libraries are written in java... If a newer java version would be enabled for android development, is there really a compelling reason to use kotlin?
kaba0 5y ago
Android’s Java is no real java, it is stuck in a strange limbo of Java 8 compatibility with some cherry-picking from fresher features, while actual Java is at 18 now with plenty of important improvements. Kotlin compiles some of these newer features’ equivalents to java 8, that’s why it is used. But that is a failure of android, not of Java.

mattbrewsbytes 5y ago

I think you could just say the world has moved on from client-side desktop apps. Doesn't matter much what language, the majority of applications are web-based and there are major negatives to having a client side install experience with patching, versioning, support, etc. Yes there are still niche domains that would need a desktop app but those are probably more rare as time goes on and/or already have established players.

mike_hearn 5y ago
Client side install experience is what mobile apps have, and everyone seems to prefer them to web apps. Web apps also have major downsides. It's easy to forget about them as developers, but for example, one is the lack of versioning. Someone pushes a new version of the app that's buggy/an UI downgrade/causes an outage and the users can't do anything about it. Often you want an app to be local because it's interacting with local data, or local hardware, or it suffers from latency, or you don't want your data to go outside your jurisdiction, or it's doing something else where distance between you and the app is problematic. Client side apps written using normal toolkits (not HTML) have a lot of major end user advantages, which is why: • Mobile apps beat web apps, despite devs trying to make users accept them (recall the history of the Facebook app for example). • HTML5 keeps sprouting features that desktop apps have had since the beginning. Filesystem access is a recent example. Any time you want your data to be independent of the apps that work with it, web apps just faceplant. In my view developers push web apps on users usually for our own convenience, e.g. being easier to bypass IT department bureaucracy. But there's a lot of ways to do better than web apps, and yes, the JVM is pretty good platform to do that on (JavaFX is a great toolkit for instance, and JetPack Compose is very interesting). What it needs is a great distribution and update solution.
- mattbrewsbytes 5y ago
  I was mostly referring to desktop app vs. web app since the OP was talking about desktop apps. Mobile apps are a different topic but they also share a set of the similar trade-offs of a desktop app with install/upgrade and support (i.e. multiple devices/versions). Pushing buggy/UI problematic software is a process/people problem not really a technology problem. I would bet the feedback loop for getting fixes in on web apps can be much shorter than client desktop apps (or mobile). Once a fix/change is tested we can have it out in production on a web app for 100% of users in 20 minutes. Stand-alone apps are a great niche where the native UI kit or other UI kits that work for the problem being solved are a great solution, there isn't a need for web tooling.