5 ms·

Hold on mate, isn't that what Java was supposed to solve. I remember before the days of electron when I was a wee lad in the 2000s, all cross platforms apps wer

Hold on mate, isn't that what Java was supposed to solve. I remember before the days of electron when I was a wee lad in the 2000s, all cross platforms apps were Java. Look at Ghidra, it's a Java app for Windows, Linux and Mac. The "holy trinity" of operating systems, covered with one language and framework. So what happened? Did devs forgot Java exists and felt like reinventing the wheel but worse this time?

zer0zzz 3y ago
Java is objectively terrible for writing good apps on modern personal computers. The one platform that did adopt it (android) had to practically rework the entire byte code and VM as well as the set of APIs for writing apps to make it work.
- FirmwareBurner 3y ago
  Why is it terrible? Asking for real.
  - LeoNatan25 3y ago
    Because it’s not “sexy” anymore. Now “sexiness” lies with web crap, so Electron is a “great tool”, while Java is “terrible”.
  - zer0zzz 3y ago
    Well, so I can only tell you as much as I know and understand. Some of this pulls in some outdated information too. So, JVMs and languages that abstract the underlying machine are always going to have overhead. The original interpreted stack-based JVM model is really bad for performance because you can't do great optimizations on the code because you can't have a great view of the operands that are being defined and then subsequently used, on top of that you have to either JIT or interpret code which also has overhead. This is why Android's original Dalvik VM originally started by converting the Sun byte code format to a register based format. So, now you have a format you can do some optimizations on: great. But you still depend on a VM to generate and optimize for native code: that means code-caches and that means using excess memory to store the fast optimized code you want to run (which could have been evicted, so more overhead when you have to regenerate). Next you have frameworks like the classic Swing in Java that were frankly implemented with priorities that did not include having a really great and responsive experience even though its platform agnostic as far as the way it draws widgets. These days we can take GPUs for granted to make this approach work, but a lot of the Java UI stuff came from another era. I am not really sure if I am right here, but to me all this means that to have made the Java system work well for modern PCs and mobile it would have required a ton of investment. As it turns out, a lot of that investment went into the web and android instead of polishing Sun and Oracle's uh... product. Java's also kinda been sidelined because for years Oracle threatened to sue anyone that dared fork it as Google had, and Microsoft kinda spent a decade making C# and .NET more confusing than it already was so theres that too.
    - FirmwareBurner 3y ago
      > The original interpreted stack-based JVM model is really bad for performance And we addressed that today by launching a copy of Chrome with every app?
      - zer0zzz 3y ago
        yes I think it's hard to beat the tide that is the web as a content and app delivery system. The web is also getting all the billions in investment from every massive faang.
      - tripleo1 3y ago
        Isn't that a tooling problem, not a language/VM problem? If the apps were distributed as PWAs, or had a shared VM (kinda like flatpak?), wouldn't that solve your nit?
    - ElectricalUnion 3y ago
      > So, JVMs and languages that abstract the underlying machine are always going to have overhead. Well, so JavaScript and WebAssebly isn't that great either in the end? > The original interpreted stack-based JVM model is really bad for performance because you can't do great optimizations on the code because you can't have a great view of the operands that are being defined and then subsequently used, on top of that you have to either JIT or interpret code which also has overhead. What a paragraph. But it's kinda false. WebAssembly, you know, is also a stack-based virtual machine. Javascript might not be a stack-based virtual machine, but you're interpreting it every time you run it for the first time. How is that faster that bytecode? It isn't. In fact, modern Javascript is fast specifically because it copies the same workflow of the Java HotSpot JIT optimizer - detect and compile code hot spots in native code, run that instead of VM code. > This is why Android's original Dalvik VM originally started by converting the Sun byte code format to a register based format. So, now you have a format you can do some optimizations on: great. But you still depend on a VM to generate and optimize for native code: that means code-caches and that means using excess memory to store the fast optimized code you want to run (which could have been evicted, so more overhead when you have to regenerate). Nope, that is totally not the reason. Dalvik was done because it was believed that you needed something that starts faster, not something that runs faster. Those are 2 different optimization targets. It was pretty known since the start of Dalvik that Dalvik had very poor throughput performance, from 10x to 2x worse that HotSpot. The reason why we don't have Dalvik anymore on Android is that it also didn't start that much faster either. That of course is not because register machines are worse either, but because nowhere near enough optimization work was done for register type VMs compared to stack type VMs in general. > Next you have frameworks like the classic Swing in Java that were frankly implemented with priorities that did not include having a really great and responsive experience even though its platform agnostic as far as the way it draws widgets. These days we can take GPUs for granted to make this approach work, but a lot of the Java UI stuff came from another era. Ok, but does your favorite, non-web GUI framework use the GPU, and use the GPU correctly at all? Even on the web it's easy to "accidentally" put some extremely expensive CSS transformations and animations and waste a whole bunch of GPU power on little things. > I am not really sure if I am right here, but to me all this means that to have made the Java system work well for modern PCs and mobile it would have required a ton of investment. As it turns out, a lot of that investment went into the web and android instead of polishing Sun and Oracle's uh... product. You're mixing things here. "Sun products" were very expensive UNIX workstations and servers. Not things for your average Joe. Those very expensive Sun workstations and servers ran Java fine. Java itself is a is very weird "Commoditize Your Complement" ( https://gwern.net/complement https://gwern.net/complement ) attempt to commoditize this exact very expensive hardware that Sun was selling. From Sun. Marketed at very high expense by Sun. A self-inflicted self-own. No wonder Sun no longer exists. > Java's also kinda been sidelined because for years Oracle threatened to sue anyone that dared fork it as Google had, and Microsoft kinda spent a decade making C# and .NET more confusing than it already was so theres that too. C# not having nice GUI is another story, that of Windows-land never having anything above pure Graphics Device Interface being stable since forever.
  - mikrotikker 3y ago
    It's got more security holes than Swiss cheese.
    - samus 3y ago
      You're living in the past. Applets and Flash lost against the HTML/JS/CSS stack and Oracle owned up to it. Applets are terminally deprecated now. Edit: admittedly, one of the reasons for that was that the sandbox was indeed prone to security holes. Also, the developer ergonomy of the SecurityManager was unsatisfying for both JDK and app developers. Good riddance.
      - mnd999 3y ago
        Applets are still a thing. We just call them webasm and canvas these days.
        samus 3y ago
        The crucial difference is that these technologies are embedded differently. Java Applets had access to dangerous APIs that had to be restricted by the SecurityManager. Also, the JVM was installed externally to the browser, turning it into an uncontrollable component which made the browser vulnerable in turn. The newer technologies were designed from the beginning with a well-defined security boundary and are based on a language that was designed from the beginning to be embedded. Everything is implemented within the browser and can be updated together with it.
      - mikrotikker 3y ago
        I'm living in the future. We have golang and rust now. Java is a pile of junk and should be relegated to the past.
        samus 3y ago
        Golang's only consistent advantage over Java is lower latency on compilation, startup, and GC. OpenJDK will eventually level the playing field with Project Valhalla. In terms of FFI and language features Java has already caught up. And faster startup can be achieved with CRaC. Rust in turn is not competing with Java.
creesch 3y ago
Java simply has a much higher barrier of entry. Not only in regards to figuring out the language and resources available but also the fact that creating a GUI still requires external dependencies. Electron isn't just cross platform, it is cross platform based on technologies (html, css and javascript) that also by a huge margin have the largest amount of developers available.
- whartung 3y ago
  > Not only in regards to figuring out the language and resources available but also the fact that creating a GUI still requires external dependencies. What external dependencies does Java need that's not in the JDK itself? I have an app with Mac and Windows installers (and thus bundles JDKs), it also runs on Linux (via a fat jar), I tested it on Ubuntu, but for the life of me I couldn't figure out how to package it properly. It was more complicated that I cared to invest it at the time. As for the barrier to entry, I feel the same way about the web. I find the JS and Web ecosystem to be utterly overwhelming, one reason I stuck with Java over something like Electron, and the installers/footprint of the app are smaller to boot.
  - creesch 3y ago
    > What external dependencies does Java need that's not in the JDK itself? I mean that it doesn't come with Java itself, but you as a developer need to pick a UI framework and not all of them actually work all that well cross platform or will get you an actual modern interface. Edit: I should also note that the threshold for entry I am talking about is for people just generally starting out. There simply are way more resources available for web related development than there are for java. Also, when you start bundling your JDKs I am not sure you can talk about a smaller footprint anymore.
    - ElectricalUnion 3y ago
      > Also, when you start bundling your JDKs I am not sure you can talk about a smaller footprint anymore. What, do you bundle Electron source and Electron build environment with your Electron app? Why would you do the same and bundle Java source code + Java compilers in your Java app? Why would you do the same and bundle <any language> source code + <any language> compilers in your <any language> app? If you need to create a "just works without dependency b.s." experience in Java, you use the correct tooling for that, jlink.
zlg_codes 3y ago
It's the JS kiddies. They got Node and then decided the whole world should be written in Javascript, lol.
chefandy 3y ago
Java is great for making huge well-organized codebases with a lot of developers, especially if you've got good tooling support or a rich ecosystem of existing code to work with. Outside of that... If it was a good development ecosystem for native gui-based apps targeted at end users, why wouldn't the preponderance of native user-facing apps be written in Java, anyway? Ask nearly any experienced mobile app developer if they're more productive in Java on Android or Swift on iOS-- it's not even close. Sure, some of that is the OS itself, but a whole lot of it isn't. On the desktop, the one time I tried to make something with Swing I wanted to Fling my computer out the window. Clunky.
- skydhash 3y ago
  It’s about branding. Swing and JavaFX looks like other desktop app (aka not cool to a lot of designers). And it has a high barrier of entry (ever tried QT, AppKit or Win32). Electron is easy, but it’s shoehorning a document process to software interfaces.
  - chefandy 3y ago
    Yeah the architecture for electron is absurd, but it's important to not relegate UI flexibility to mere aesthetics. For most of my career, I was a back-end web developer, but more recently I've done a lot of interface design after getting some formal education in it. The overwhelming majority of developers I've worked and interacted with conflate aesthetic and interface usability. Heck, even I did before I really started digging into it professionally. I think it's because applications that have experienced designers make a good, usable interfaces will also likely hire visual designers to do aesthetic/branding work, and especially in waterfall environments, developers get it all handed to them as a "design." And for many reasons I will (uncharacteristically) not rehash here, FOSS lacks both. However, a good interface and a pretty interface are not the same thing-- both are communication mediums that communicate through the software interface, but visual/branding/identity designers communicate things to the user about the brand as a marketing device, and interface designers figure out how to communicate the software's features, status, output, etc. with the greatest efficiency and reduce unnecessary cognitive overhead. Branding and identity is a very specialized form of design that's usually done by design houses-- even huge companies with big teams of designers often contract this work out to specialists. They might go so far as to recommend certain animations for interaction, but you don't want them designing your interface. In small companies, the designer will probably have to implement their design to conform to the design document, but they're using tools like gestalt, alignment, color grouping and type to create information hierarchies, existing expectations for layout and functionality, etc. that tell the user what they need to know as effectively as possible, and how to act on that in the ways they need to. A good example of the power of interface design is in many dark patterns. You can simply have a plain system-standard dialog box asking if a user consents to some creepy analytics that nobody really wants, but instead of "OK" and "Cancel" in their normal spots, put "Off" in bold letters where "Ok" would normally be, and "Consent" in non-bold letters where "Cancel" would normally be, and I'll bet you at least 60% of users would choose "Consent" having only skimmed the familiar pattern. That experience isn't branded or styled in any way-- it solely uses juxtaposition, pattern expectations, and context to influence users behavior. When you've got an inflexible, counterintuitive UI kit that developers must fight with to get the results the interface designer carefully put together, you hurt the usability of that tool for end users a hell of a lot more than mediocre performance does. This is very counterintuitive for most developers because of the curse of expertise. We have a working mental model of how software works on the back end and consider the interface a tool to expose that functionality to the user. To users, the interface is the software, and if you're design is more informed by the way the software works under the hood than the way a nontechnical user thinks about solving the problem they're trying to solve, it's going to be very frustrating for everyone who isn't a developer. Developers like to talk about marketing as the primary reason commercial software is king, and it's definitely a factor, but developers aren't magically immune to marketing, and you can't get much more compelling than "Free." To most users, the frustration of dealing with interfaces designed by and (inadvertently) for developers is worse than paying for software--- hence FOSS nearly exclusively being adopted by technical people.
em-bee 3y ago
when i see a java application i think, hmm, this is likely going to be bloated (but not necessarily) but for sure it's going to run. if i want to create a cross platform application where i don't even have to think about testing on multiple operating systems, then java is going to be a serious contender. and if i have to choose between an app written in java or electron, i'd probably pick the one in java. so yeah, i don't understand what happened here either.
paulddraper 3y ago
If Java applets were anywhere as popular as JavaScript web apps, I'm sure Java desktop would be as popular as Election. But Java applets aren't popular.
account42 3y ago
The JRE itself is an external dependency that you need to bunle because it is not part of most Linux distributions. And even if there is a JRE installed it is not guaranteed to be able to run your Java application. So yeah if you redefine your problem to "run on systems with the right JRE" then Java makes things "easy" (your program will still stick out like an unpolished turd). But if you can just require stuff like that than you can also require the right dependency versions for native programs.

zer0zzz 3y ago

Java is objectively terrible for writing good apps on modern personal computers. The one platform that did adopt it (android) had to practically rework the entire byte code and VM as well as the set of APIs for writing apps to make it work.

FirmwareBurner 3y ago
Why is it terrible? Asking for real.
- LeoNatan25 3y ago
  Because it’s not “sexy” anymore. Now “sexiness” lies with web crap, so Electron is a “great tool”, while Java is “terrible”.
- zer0zzz 3y ago
  Well, so I can only tell you as much as I know and understand. Some of this pulls in some outdated information too. So, JVMs and languages that abstract the underlying machine are always going to have overhead. The original interpreted stack-based JVM model is really bad for performance because you can't do great optimizations on the code because you can't have a great view of the operands that are being defined and then subsequently used, on top of that you have to either JIT or interpret code which also has overhead. This is why Android's original Dalvik VM originally started by converting the Sun byte code format to a register based format. So, now you have a format you can do some optimizations on: great. But you still depend on a VM to generate and optimize for native code: that means code-caches and that means using excess memory to store the fast optimized code you want to run (which could have been evicted, so more overhead when you have to regenerate). Next you have frameworks like the classic Swing in Java that were frankly implemented with priorities that did not include having a really great and responsive experience even though its platform agnostic as far as the way it draws widgets. These days we can take GPUs for granted to make this approach work, but a lot of the Java UI stuff came from another era. I am not really sure if I am right here, but to me all this means that to have made the Java system work well for modern PCs and mobile it would have required a ton of investment. As it turns out, a lot of that investment went into the web and android instead of polishing Sun and Oracle's uh... product. Java's also kinda been sidelined because for years Oracle threatened to sue anyone that dared fork it as Google had, and Microsoft kinda spent a decade making C# and .NET more confusing than it already was so theres that too.
  - FirmwareBurner 3y ago
    > The original interpreted stack-based JVM model is really bad for performance And we addressed that today by launching a copy of Chrome with every app?
    - zer0zzz 3y ago
      yes I think it's hard to beat the tide that is the web as a content and app delivery system. The web is also getting all the billions in investment from every massive faang.
    - tripleo1 3y ago
      Isn't that a tooling problem, not a language/VM problem? If the apps were distributed as PWAs, or had a shared VM (kinda like flatpak?), wouldn't that solve your nit?
  - ElectricalUnion 3y ago
    > So, JVMs and languages that abstract the underlying machine are always going to have overhead. Well, so JavaScript and WebAssebly isn't that great either in the end? > The original interpreted stack-based JVM model is really bad for performance because you can't do great optimizations on the code because you can't have a great view of the operands that are being defined and then subsequently used, on top of that you have to either JIT or interpret code which also has overhead. What a paragraph. But it's kinda false. WebAssembly, you know, is also a stack-based virtual machine. Javascript might not be a stack-based virtual machine, but you're interpreting it every time you run it for the first time. How is that faster that bytecode? It isn't. In fact, modern Javascript is fast specifically because it copies the same workflow of the Java HotSpot JIT optimizer - detect and compile code hot spots in native code, run that instead of VM code. > This is why Android's original Dalvik VM originally started by converting the Sun byte code format to a register based format. So, now you have a format you can do some optimizations on: great. But you still depend on a VM to generate and optimize for native code: that means code-caches and that means using excess memory to store the fast optimized code you want to run (which could have been evicted, so more overhead when you have to regenerate). Nope, that is totally not the reason. Dalvik was done because it was believed that you needed something that starts faster, not something that runs faster. Those are 2 different optimization targets. It was pretty known since the start of Dalvik that Dalvik had very poor throughput performance, from 10x to 2x worse that HotSpot. The reason why we don't have Dalvik anymore on Android is that it also didn't start that much faster either. That of course is not because register machines are worse either, but because nowhere near enough optimization work was done for register type VMs compared to stack type VMs in general. > Next you have frameworks like the classic Swing in Java that were frankly implemented with priorities that did not include having a really great and responsive experience even though its platform agnostic as far as the way it draws widgets. These days we can take GPUs for granted to make this approach work, but a lot of the Java UI stuff came from another era. Ok, but does your favorite, non-web GUI framework use the GPU, and use the GPU correctly at all? Even on the web it's easy to "accidentally" put some extremely expensive CSS transformations and animations and waste a whole bunch of GPU power on little things. > I am not really sure if I am right here, but to me all this means that to have made the Java system work well for modern PCs and mobile it would have required a ton of investment. As it turns out, a lot of that investment went into the web and android instead of polishing Sun and Oracle's uh... product. You're mixing things here. "Sun products" were very expensive UNIX workstations and servers. Not things for your average Joe. Those very expensive Sun workstations and servers ran Java fine. Java itself is a is very weird "Commoditize Your Complement" ( https://gwern.net/complement https://gwern.net/complement ) attempt to commoditize this exact very expensive hardware that Sun was selling. From Sun. Marketed at very high expense by Sun. A self-inflicted self-own. No wonder Sun no longer exists. > Java's also kinda been sidelined because for years Oracle threatened to sue anyone that dared fork it as Google had, and Microsoft kinda spent a decade making C# and .NET more confusing than it already was so theres that too. C# not having nice GUI is another story, that of Windows-land never having anything above pure Graphics Device Interface being stable since forever.
- mikrotikker 3y ago
  It's got more security holes than Swiss cheese.
  - samus 3y ago
    You're living in the past. Applets and Flash lost against the HTML/JS/CSS stack and Oracle owned up to it. Applets are terminally deprecated now. Edit: admittedly, one of the reasons for that was that the sandbox was indeed prone to security holes. Also, the developer ergonomy of the SecurityManager was unsatisfying for both JDK and app developers. Good riddance.
    - mnd999 3y ago
      Applets are still a thing. We just call them webasm and canvas these days.
      - samus 3y ago
        The crucial difference is that these technologies are embedded differently. Java Applets had access to dangerous APIs that had to be restricted by the SecurityManager. Also, the JVM was installed externally to the browser, turning it into an uncontrollable component which made the browser vulnerable in turn. The newer technologies were designed from the beginning with a well-defined security boundary and are based on a language that was designed from the beginning to be embedded. Everything is implemented within the browser and can be updated together with it.
    - mikrotikker 3y ago
      I'm living in the future. We have golang and rust now. Java is a pile of junk and should be relegated to the past.
      - samus 3y ago
        Golang's only consistent advantage over Java is lower latency on compilation, startup, and GC. OpenJDK will eventually level the playing field with Project Valhalla. In terms of FFI and language features Java has already caught up. And faster startup can be achieved with CRaC. Rust in turn is not competing with Java.

creesch 3y ago

Java simply has a much higher barrier of entry. Not only in regards to figuring out the language and resources available but also the fact that creating a GUI still requires external dependencies. Electron isn't just cross platform, it is cross platform based on technologies (html, css and javascript) that also by a huge margin have the largest amount of developers available.

whartung 3y ago
> Not only in regards to figuring out the language and resources available but also the fact that creating a GUI still requires external dependencies. What external dependencies does Java need that's not in the JDK itself? I have an app with Mac and Windows installers (and thus bundles JDKs), it also runs on Linux (via a fat jar), I tested it on Ubuntu, but for the life of me I couldn't figure out how to package it properly. It was more complicated that I cared to invest it at the time. As for the barrier to entry, I feel the same way about the web. I find the JS and Web ecosystem to be utterly overwhelming, one reason I stuck with Java over something like Electron, and the installers/footprint of the app are smaller to boot.
- creesch 3y ago
  > What external dependencies does Java need that's not in the JDK itself? I mean that it doesn't come with Java itself, but you as a developer need to pick a UI framework and not all of them actually work all that well cross platform or will get you an actual modern interface. Edit: I should also note that the threshold for entry I am talking about is for people just generally starting out. There simply are way more resources available for web related development than there are for java. Also, when you start bundling your JDKs I am not sure you can talk about a smaller footprint anymore.
  - ElectricalUnion 3y ago
    > Also, when you start bundling your JDKs I am not sure you can talk about a smaller footprint anymore. What, do you bundle Electron source and Electron build environment with your Electron app? Why would you do the same and bundle Java source code + Java compilers in your Java app? Why would you do the same and bundle <any language> source code + <any language> compilers in your <any language> app? If you need to create a "just works without dependency b.s." experience in Java, you use the correct tooling for that, jlink.

zlg_codes 3y ago

It's the JS kiddies. They got Node and then decided the whole world should be written in Javascript, lol.

chefandy 3y ago

Java is great for making huge well-organized codebases with a lot of developers, especially if you've got good tooling support or a rich ecosystem of existing code to work with. Outside of that... If it was a good development ecosystem for native gui-based apps targeted at end users, why wouldn't the preponderance of native user-facing apps be written in Java, anyway? Ask nearly any experienced mobile app developer if they're more productive in Java on Android or Swift on iOS-- it's not even close. Sure, some of that is the OS itself, but a whole lot of it isn't. On the desktop, the one time I tried to make something with Swing I wanted to Fling my computer out the window. Clunky.

skydhash 3y ago
It’s about branding. Swing and JavaFX looks like other desktop app (aka not cool to a lot of designers). And it has a high barrier of entry (ever tried QT, AppKit or Win32). Electron is easy, but it’s shoehorning a document process to software interfaces.
- chefandy 3y ago
  Yeah the architecture for electron is absurd, but it's important to not relegate UI flexibility to mere aesthetics. For most of my career, I was a back-end web developer, but more recently I've done a lot of interface design after getting some formal education in it. The overwhelming majority of developers I've worked and interacted with conflate aesthetic and interface usability. Heck, even I did before I really started digging into it professionally. I think it's because applications that have experienced designers make a good, usable interfaces will also likely hire visual designers to do aesthetic/branding work, and especially in waterfall environments, developers get it all handed to them as a "design." And for many reasons I will (uncharacteristically) not rehash here, FOSS lacks both. However, a good interface and a pretty interface are not the same thing-- both are communication mediums that communicate through the software interface, but visual/branding/identity designers communicate things to the user about the brand as a marketing device, and interface designers figure out how to communicate the software's features, status, output, etc. with the greatest efficiency and reduce unnecessary cognitive overhead. Branding and identity is a very specialized form of design that's usually done by design houses-- even huge companies with big teams of designers often contract this work out to specialists. They might go so far as to recommend certain animations for interaction, but you don't want them designing your interface. In small companies, the designer will probably have to implement their design to conform to the design document, but they're using tools like gestalt, alignment, color grouping and type to create information hierarchies, existing expectations for layout and functionality, etc. that tell the user what they need to know as effectively as possible, and how to act on that in the ways they need to. A good example of the power of interface design is in many dark patterns. You can simply have a plain system-standard dialog box asking if a user consents to some creepy analytics that nobody really wants, but instead of "OK" and "Cancel" in their normal spots, put "Off" in bold letters where "Ok" would normally be, and "Consent" in non-bold letters where "Cancel" would normally be, and I'll bet you at least 60% of users would choose "Consent" having only skimmed the familiar pattern. That experience isn't branded or styled in any way-- it solely uses juxtaposition, pattern expectations, and context to influence users behavior. When you've got an inflexible, counterintuitive UI kit that developers must fight with to get the results the interface designer carefully put together, you hurt the usability of that tool for end users a hell of a lot more than mediocre performance does. This is very counterintuitive for most developers because of the curse of expertise. We have a working mental model of how software works on the back end and consider the interface a tool to expose that functionality to the user. To users, the interface is the software, and if you're design is more informed by the way the software works under the hood than the way a nontechnical user thinks about solving the problem they're trying to solve, it's going to be very frustrating for everyone who isn't a developer. Developers like to talk about marketing as the primary reason commercial software is king, and it's definitely a factor, but developers aren't magically immune to marketing, and you can't get much more compelling than "Free." To most users, the frustration of dealing with interfaces designed by and (inadvertently) for developers is worse than paying for software--- hence FOSS nearly exclusively being adopted by technical people.

em-bee 3y ago

when i see a java application i think, hmm, this is likely going to be bloated (but not necessarily) but for sure it's going to run. if i want to create a cross platform application where i don't even have to think about testing on multiple operating systems, then java is going to be a serious contender. and if i have to choose between an app written in java or electron, i'd probably pick the one in java. so yeah, i don't understand what happened here either.

paulddraper 3y ago

If Java applets were anywhere as popular as JavaScript web apps, I'm sure Java desktop would be as popular as Election. But Java applets aren't popular.

account42 3y ago

The JRE itself is an external dependency that you need to bunle because it is not part of most Linux distributions. And even if there is a JRE installed it is not guaranteed to be able to run your Java application. So yeah if you redefine your problem to "run on systems with the right JRE" then Java makes things "easy" (your program will still stick out like an unpolished turd). But if you can just require stuff like that than you can also require the right dependency versions for native programs.