6 ms·

This skips the steps of choosing and installing a JVM, which is a bit daunting. My distro gives like 4 different versions. And worse, some applications only r

by axaxs 6y ago

This skips the steps of choosing and installing a JVM, which is a bit daunting. My distro gives like 4 different versions. And worse, some applications only run on certain versions. By default, there is no 'java' command.

weego 6y ago
That's not really a good faith argument. That's the equivalent of saying that a major problem with NodeJS is you have to pick which version to install before you deploy. I deploy single package jvm files most days having not had to consider the deploy environment for a about 4 years.
- femiagbabiaka 6y ago
  It is a good faith argument — it’s literally the whole point. Native binaries bypass all of that.
  - Tsarbomb 6y ago
    Good luck when you need to deploy to a system with a different version of libc.
    - splix 6y ago
      Also with different version of openssl
    - femiagbabiaka 6y ago
      goalposts are moving at a rapid pace
      - tamale 6y ago
        having a different version of libc is exactly like worrying that the system has a different version of java. If you know about these 'gotchas', they're not big deal. If you don't, then ya, they can be a bit intimidating at first. I really don't think running a go app vs. a java app is ANY different.
        femiagbabiaka 6y ago
        I’m trying to figure out what environments you’re working in where libc incompatibilities are as common as java versioning issues You’ve made a straw man and are now working very hard to defend it.
- jooz 6y ago
  What is hard is not to choose the java version (1.8,19,...), but the JVM implementation. To choose between hotspot, openjdk, oracle. Even to find the download link without being forced to log in on oracle.com was difficult (in fact I couldnt find it the very last time).
  - npstr 6y ago
    Have a look at https://sdkman.io https://sdkman.io
  - Groxx 6y ago
    Why is it hard? Since Go gives you no choice, the equivalent would be to pick literally any, and make do with its defaults. Same thing for tuning. You do not have to choose optimally, that's an extra constraint.
- morelisp 6y ago
  > That's the equivalent of saying that a major problem with NodeJS is you have to pick which version to install before you deploy. Are you saying this isn't a major problem with Node? In my experience it's a problem with every language that requires a separate runtime. The JVM is the worst of two worlds because I have the build complexity of an AOT compiler to make my deployment artifact and the deployment complexity of an interpreted language to get the correct runtime pre-installed.
  - Tsarbomb 6y ago
    You do realize Java has maintained it's backwards compatibility making choosing your deployment runtime significantly easier.
karmakaze 6y ago
This is a question you have to answer once for your project. Similar to choosing which OS, database, library, or framework to use. There's no avoiding having knowledge or learning when choosing dependencies. Just about any of the implentations will work fine. You only have to concern yourself with avoiding use of the Oracle runtime in production without a license. If in doubt, install the latest AdoptOpenJDK[0] Hotspot version that's compatible with your app. [0] https://adoptopenjdk.net/ https://adoptopenjdk.net/
apta 6y ago
You can ship the JVM with your app such that it's self-contained and system independent. Apps like IntelliJ already do this. And now with jlink, you can strip it down to make deployment sizes even smaller by only shipping the parts of the JVM that your app uses.

by axaxs 6y ago

weego 6y ago

That's not really a good faith argument. That's the equivalent of saying that a major problem with NodeJS is you have to pick which version to install before you deploy. I deploy single package jvm files most days having not had to consider the deploy environment for a about 4 years.

femiagbabiaka 6y ago
It is a good faith argument — it’s literally the whole point. Native binaries bypass all of that.
- Tsarbomb 6y ago
  Good luck when you need to deploy to a system with a different version of libc.
  - splix 6y ago
    Also with different version of openssl
  - femiagbabiaka 6y ago
    goalposts are moving at a rapid pace
    - tamale 6y ago
      having a different version of libc is exactly like worrying that the system has a different version of java. If you know about these 'gotchas', they're not big deal. If you don't, then ya, they can be a bit intimidating at first. I really don't think running a go app vs. a java app is ANY different.
      - femiagbabiaka 6y ago
        I’m trying to figure out what environments you’re working in where libc incompatibilities are as common as java versioning issues You’ve made a straw man and are now working very hard to defend it.
jooz 6y ago
What is hard is not to choose the java version (1.8,19,...), but the JVM implementation. To choose between hotspot, openjdk, oracle. Even to find the download link without being forced to log in on oracle.com was difficult (in fact I couldnt find it the very last time).
- npstr 6y ago
  Have a look at https://sdkman.io https://sdkman.io
- Groxx 6y ago
  Why is it hard? Since Go gives you no choice, the equivalent would be to pick literally any, and make do with its defaults. Same thing for tuning. You do not have to choose optimally, that's an extra constraint.
morelisp 6y ago
> That's the equivalent of saying that a major problem with NodeJS is you have to pick which version to install before you deploy. Are you saying this isn't a major problem with Node? In my experience it's a problem with every language that requires a separate runtime. The JVM is the worst of two worlds because I have the build complexity of an AOT compiler to make my deployment artifact and the deployment complexity of an interpreted language to get the correct runtime pre-installed.
- Tsarbomb 6y ago
  You do realize Java has maintained it's backwards compatibility making choosing your deployment runtime significantly easier.

karmakaze 6y ago

This is a question you have to answer once for your project. Similar to choosing which OS, database, library, or framework to use. There's no avoiding having knowledge or learning when choosing dependencies. Just about any of the implentations will work fine. You only have to concern yourself with avoiding use of the Oracle runtime in production without a license. If in doubt, install the latest AdoptOpenJDK[0] Hotspot version that's compatible with your app. [0] https://adoptopenjdk.net/ https://adoptopenjdk.net/

apta 6y ago

You can ship the JVM with your app such that it's self-contained and system independent. Apps like IntelliJ already do this. And now with jlink, you can strip it down to make deployment sizes even smaller by only shipping the parts of the JVM that your app uses.