3 ms·

> How are Jars more portable than Go binaries when you need Java installed to run Jars? Uh, you don't...? https://docs.oracle.com/en/java/javase/14/docs/specs

> How are Jars more portable than Go binaries when you need Java installed to run Jars? Uh, you don't...? https://docs.oracle.com/en/java/javase/14/docs/specs/man/jpackage.html https://docs.oracle.com/en/java/javase/14/docs/specs/man/jpa... > you don't need many libraries to begin with. This really depends on what you're doing. Having many libraries creates a lot of weird potential. You can absolutely subsist on less, but you can do more with more. A while back I found myself wanting to render MathML into an image. So I dug up jeuclid which is absolutely antique and as far as I can tell not actively maintained. My project flat out would have ended there if I had to build my own math rendering engine to proceed.

pdpi 4y ago
> Each format must be built on the platform it runs on, there is no cross-platform support. So now you're back to platform-specific packages, except you don't have Go's support for cross-compilation. Hardly much of an advantage.
- mike_hearn 4y ago
  You can make self-updating packages of JVM apps for Windows, macOS and Linux from your local OS ("cross compiled") using Conveyor: https://conveyor.hydraulic.dev/ https://conveyor.hydraulic.dev/ It's not JVM specific but it does understand how to bundle the JVM, use jlink to shrink it, read your classpath from Gradle etc.
- marginalia_nu 4y ago
  Well yeah. You've still got jars though if you want architecture independence. Java's not really aiming at the desktop market though. It's a server language first and foremost. You're most likely setting up a machine (or VM or container) to cater to the Java code you're running. But to be realistic, most Java code either runs in application servers (as WARs) or in containers, and in the latter case, even though your java jars are architecture independent, docker just isn't.
- pjmlp 4y ago
  Go only does cross-compilation when using the standard library and pure Go libraries, hardly any different. Plus the target OS needs to exist on the toolchain anyway.

pdpi 4y ago

> Each format must be built on the platform it runs on, there is no cross-platform support. So now you're back to platform-specific packages, except you don't have Go's support for cross-compilation. Hardly much of an advantage.

mike_hearn 4y ago
You can make self-updating packages of JVM apps for Windows, macOS and Linux from your local OS ("cross compiled") using Conveyor: https://conveyor.hydraulic.dev/ https://conveyor.hydraulic.dev/ It's not JVM specific but it does understand how to bundle the JVM, use jlink to shrink it, read your classpath from Gradle etc.
marginalia_nu 4y ago
Well yeah. You've still got jars though if you want architecture independence. Java's not really aiming at the desktop market though. It's a server language first and foremost. You're most likely setting up a machine (or VM or container) to cater to the Java code you're running. But to be realistic, most Java code either runs in application servers (as WARs) or in containers, and in the latter case, even though your java jars are architecture independent, docker just isn't.
pjmlp 4y ago
Go only does cross-compilation when using the standard library and pure Go libraries, hardly any different. Plus the target OS needs to exist on the toolchain anyway.