12 ms·

> 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 U

> 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.
- creesch 3y ago
  > If you need to create a "just works without dependency b.s." experience in Java, you use the correct tooling for that, jlink. At which point you are including a similar footprint as Electron does by shipping chrome. I mean, you must have realized I was talking about the inclusion of the JRE and whatever else is needed to make a java application run on a system as a standalone application. So I am honestly not sure what you are arguing besides semantics.
whartung 3y ago
Well, Swing is still bundled with Java. Netbeans uses the "Flat Look and Feel" and looks ok to me. I find Swing a lot more work compared to FX. JavaFX used to be bundled with Java, but was removed. Some JDK distributions bundle FX like it was before, and adding FX to a new project is simple and straight forward. Maven packages it nicely, and it includes the platform specific binary parts. If you can use Log4j, you can use Java FX. Onboarding onto FX is not a high bar. I can not speak to SWT. There's several examples of "modern" UIs in FX, I can't speak to any of them, I don't pay much attention to that space. It's imperfect compared to the web, but not impossible.
- chefandy 3y ago
  Java FX seems better than swing, but it's an external dependency now though, isn't it? I thought it got removed from the jdk a few years ago.
  - whartung 3y ago
    It was. Even before it was more "bundled" with the JDK than "part of Java". But, to be honest, that's a real nit. It's a standalone dependency, it's 4 lines in a POM file, it doesn't drag the internet with it, and it only relies on the JDK. So, while it's a large subsystem, it's a "low impact" dependency in terms of side affects and complexity.
    - ausbin 3y ago
      > it's a "low impact" dependency in terms of side affects and complexity. I wish that were true in my experience. But we have struggled to support {macOS, Windows, Linux} x {x86_64, arm64} with JavaFX and one .jar for our application. This is a 250-line diff, not a 4-line diff: https://github.com/ra4king/CircuitSim/pull/93/files https://github.com/ra4king/CircuitSim/pull/93/files. We have to manually manage .dlls and .sos by hand. If you know a solution that is 4 lines, we would be very grateful. All we want is one .jar with JavaFX in it that supports many OSs and architectures.
      - whartung 3y ago
        Not sure what your requirements are. My point about 4 line dependency is to point out that the barrier to entry into FX is low. What you are doing I would consider unconventional, as demonstrated by all of the hoops you're jumping through to achieve it. Packaging, yes, is still a bit arcane at this point. My project, https://github.com/willhartung/planet https://github.com/willhartung/planet packages macOS and Windows installers, and can be run as a fat jar on a Linux machine (tested on Ubuntu). You can look in there to see my POM file, and my build scripts. They're much simpler than what you're doing. I don't have a package for Linux, as I mentioned earlier, it was just a bit to confusing to figure out Linux packaging for my tastes, so I punted. If there was crushing demand for it, I'd look into it deeper. None of those artifacts are "cross platform". It's not a single artifact for all platforms, they are platform specific. I build the Mac one on my machine, and the Windows and Linux versions on VMs. Currently, the vision for Java distribution is to bundle the runtime with the application. Use jlink and the module system to narrow down your JRE, and jpackage to combine them into an appropriate, platform artifact. jpackage requires to be run on the host OSs. I do not have ARM versions of any of my code yet. If you want to ship a cross platform jar, then it's probably worth your time to require a JDK with FX already installed. Azul does this, I think there are others. Then the FX, and it's platform specific binaries, are no longer your applications problem. Also, there is a project, https://jdeploy.com https://jdeploy.com that offers tooling and infrastructure to distribute native FX bundles, it even offers automatic updates. It will install its own JDK in its own directory structure to run your applications. If you have multiple applications, it will share the JDKs among them. It's quite clever, and perhaps worth considering depending on your requirements. I chose to not do that just to make my projects as simple as practical for the end user and myself. I'll be fair, getting to this point was not drag and drop. jpackage and jlink can be fiddly to get started with. Documentation can always be better.

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.

creesch 3y ago
> If you need to create a "just works without dependency b.s." experience in Java, you use the correct tooling for that, jlink. At which point you are including a similar footprint as Electron does by shipping chrome. I mean, you must have realized I was talking about the inclusion of the JRE and whatever else is needed to make a java application run on a system as a standalone application. So I am honestly not sure what you are arguing besides semantics.

whartung 3y ago

Well, Swing is still bundled with Java. Netbeans uses the "Flat Look and Feel" and looks ok to me. I find Swing a lot more work compared to FX. JavaFX used to be bundled with Java, but was removed. Some JDK distributions bundle FX like it was before, and adding FX to a new project is simple and straight forward. Maven packages it nicely, and it includes the platform specific binary parts. If you can use Log4j, you can use Java FX. Onboarding onto FX is not a high bar. I can not speak to SWT. There's several examples of "modern" UIs in FX, I can't speak to any of them, I don't pay much attention to that space. It's imperfect compared to the web, but not impossible.

chefandy 3y ago
Java FX seems better than swing, but it's an external dependency now though, isn't it? I thought it got removed from the jdk a few years ago.
- whartung 3y ago
  It was. Even before it was more "bundled" with the JDK than "part of Java". But, to be honest, that's a real nit. It's a standalone dependency, it's 4 lines in a POM file, it doesn't drag the internet with it, and it only relies on the JDK. So, while it's a large subsystem, it's a "low impact" dependency in terms of side affects and complexity.
  - ausbin 3y ago
    > it's a "low impact" dependency in terms of side affects and complexity. I wish that were true in my experience. But we have struggled to support {macOS, Windows, Linux} x {x86_64, arm64} with JavaFX and one .jar for our application. This is a 250-line diff, not a 4-line diff: https://github.com/ra4king/CircuitSim/pull/93/files https://github.com/ra4king/CircuitSim/pull/93/files. We have to manually manage .dlls and .sos by hand. If you know a solution that is 4 lines, we would be very grateful. All we want is one .jar with JavaFX in it that supports many OSs and architectures.
    - whartung 3y ago
      Not sure what your requirements are. My point about 4 line dependency is to point out that the barrier to entry into FX is low. What you are doing I would consider unconventional, as demonstrated by all of the hoops you're jumping through to achieve it. Packaging, yes, is still a bit arcane at this point. My project, https://github.com/willhartung/planet https://github.com/willhartung/planet packages macOS and Windows installers, and can be run as a fat jar on a Linux machine (tested on Ubuntu). You can look in there to see my POM file, and my build scripts. They're much simpler than what you're doing. I don't have a package for Linux, as I mentioned earlier, it was just a bit to confusing to figure out Linux packaging for my tastes, so I punted. If there was crushing demand for it, I'd look into it deeper. None of those artifacts are "cross platform". It's not a single artifact for all platforms, they are platform specific. I build the Mac one on my machine, and the Windows and Linux versions on VMs. Currently, the vision for Java distribution is to bundle the runtime with the application. Use jlink and the module system to narrow down your JRE, and jpackage to combine them into an appropriate, platform artifact. jpackage requires to be run on the host OSs. I do not have ARM versions of any of my code yet. If you want to ship a cross platform jar, then it's probably worth your time to require a JDK with FX already installed. Azul does this, I think there are others. Then the FX, and it's platform specific binaries, are no longer your applications problem. Also, there is a project, https://jdeploy.com https://jdeploy.com that offers tooling and infrastructure to distribute native FX bundles, it even offers automatic updates. It will install its own JDK in its own directory structure to run your applications. If you have multiple applications, it will share the JDKs among them. It's quite clever, and perhaps worth considering depending on your requirements. I chose to not do that just to make my projects as simple as practical for the end user and myself. I'll be fair, getting to this point was not drag and drop. jpackage and jlink can be fiddly to get started with. Documentation can always be better.