4 ms·

They are really simple if done correctly. You have a single fat jar so can do java -jar myapp.jar which is almost as easy as your static binary but prefixed wit

They are really simple if done correctly. You have a single fat jar so can do java -jar myapp.jar which is almost as easy as your static binary but prefixed with two extra words. It’s also trivially easy to package as a docker image. What makes things like Zookeeper and Kafka to deploy is they are complex applications. You can write them in any other language and the deployment will still remain as non trivial.

michaelt 6y ago
I use Java for a living. Whether you think Java is very easy or a pain in the ass depends on what you're doing. Consider the fact Ubuntu 18.04's default repos come with a pretty ancient version of Java. And if you want a newer version, you have to use some third-party source. And the fact there are both OpenJDK and Oracle JDKs to choose from. Will that be JDK or JRE? Headless? Depending on the combination of JDK and software, maybe the fonts will go all funny. Got multiple JDKs? Some programs will use your default Java, some will invite you to select the JDK to use, some will bundle their own complete JDK. Oh, a program uses JavaFX? No, of course that isn't installed just because you installed Java. These problems aren't inherent to Java, of course - it's 98% due to Oracle's attempts to inconvenience people into paying for licenses.
- PopeDotNinja 6y ago
  +1 for this. A headless install of Java is not straight forward. Doable? Yes. Pain in the butt? Yes.
  - elric 6y ago
    yum install java-latest-openjdk-headless There, you're done. Need fonts? Install fonts. Pain in the butt? Where?
    - bsaul 6y ago
      And now you have a separate intermediate runtime layer between your code and the OS, with its own set of versions, patches, regression, bugs, backward compatibilities, etc. that may or may not have an impact on the code that you intend to deploy (or redeploy). Statically compiled binaries are undoubtedly a plus regarding deployment.
      - throwdbaaway 6y ago
        You do realize that golang statically compiled binaries contain the go runtime right? So, all the concerns that you mentioned are applicable to go as well, e.g. a golang app may be buggy when built with version X, while another golang app may have GC issue when built with version Y, and yet another golang app would be vulnerable unless rebuilt with version Z. [1][2][3] Don't drink the Kool-Aid, golang is just a more opinionated and much less capable cousin of Java/JVM. And for many companies, that could be the right trade-off. [1] https://groups.google.com/forum/m/#!topic/golang-announce/mVeX35iXuSw https://groups.google.com/forum/m/#!topic/golang-announce/mV... [2] https://groups.google.com/forum/m/#!topic/kubernetes-security-announce/PtsUCqFi4h4 https://groups.google.com/forum/m/#!topic/kubernetes-securit... [3] https://groups.google.com/forum/m/#!topic/golang-announce/65QixT3tcmg https://groups.google.com/forum/m/#!topic/golang-announce/65...
        bsaul 6y ago
        except that the developer controls it, since its is embedded. As such it follows the exact same lifecycle as the code itself ( versionning, testing, etc).
        vips7L 6y ago
        This is misinformed. jlink has existed since jdk 11 and allows the developer to produce a custom JVM to ship with their application. jpackage also now exists to create installers for whatever platform your on. It is you the developer who are responsible for packaging your application correctly.
        6y ago
- elric 6y ago
  I don't know which JVMs are or aren't in Ubuntu. But Ubuntu 18 is over 2 years old. Almost every major linux distribution has stable, LTS versions of Java 8 and 11 -- which are the currently supported LTS versions in general. A package can easily add a dependency on a specific Java version. And unlike many other tools, if you have multiple versions of Java, all you usually need to do is add the right one to the $PATH. Sometimes you may have to set $JRE_HOME. And that's it. You're done. If that's too much of a pain to deal with, I hope you never have to install a tool that requires a specific PHP, Python or NodeJS version. I don't know of any serious tools written in Java that don't either explicitly say which version(s) are supported. Maybe some tools are poorly packaged. But again, that's not a problem with Java.
  - apta 6y ago
    You can also ship the JVM directly with your product, that way it's system independent. Even better with jlink.

michaelt 6y ago

I use Java for a living. Whether you think Java is very easy or a pain in the ass depends on what you're doing. Consider the fact Ubuntu 18.04's default repos come with a pretty ancient version of Java. And if you want a newer version, you have to use some third-party source. And the fact there are both OpenJDK and Oracle JDKs to choose from. Will that be JDK or JRE? Headless? Depending on the combination of JDK and software, maybe the fonts will go all funny. Got multiple JDKs? Some programs will use your default Java, some will invite you to select the JDK to use, some will bundle their own complete JDK. Oh, a program uses JavaFX? No, of course that isn't installed just because you installed Java. These problems aren't inherent to Java, of course - it's 98% due to Oracle's attempts to inconvenience people into paying for licenses.

PopeDotNinja 6y ago
+1 for this. A headless install of Java is not straight forward. Doable? Yes. Pain in the butt? Yes.
- elric 6y ago
  yum install java-latest-openjdk-headless There, you're done. Need fonts? Install fonts. Pain in the butt? Where?
  - bsaul 6y ago
    And now you have a separate intermediate runtime layer between your code and the OS, with its own set of versions, patches, regression, bugs, backward compatibilities, etc. that may or may not have an impact on the code that you intend to deploy (or redeploy). Statically compiled binaries are undoubtedly a plus regarding deployment.
    - throwdbaaway 6y ago
      You do realize that golang statically compiled binaries contain the go runtime right? So, all the concerns that you mentioned are applicable to go as well, e.g. a golang app may be buggy when built with version X, while another golang app may have GC issue when built with version Y, and yet another golang app would be vulnerable unless rebuilt with version Z. [1][2][3] Don't drink the Kool-Aid, golang is just a more opinionated and much less capable cousin of Java/JVM. And for many companies, that could be the right trade-off. [1] https://groups.google.com/forum/m/#!topic/golang-announce/mVeX35iXuSw https://groups.google.com/forum/m/#!topic/golang-announce/mV... [2] https://groups.google.com/forum/m/#!topic/kubernetes-security-announce/PtsUCqFi4h4 https://groups.google.com/forum/m/#!topic/kubernetes-securit... [3] https://groups.google.com/forum/m/#!topic/golang-announce/65QixT3tcmg https://groups.google.com/forum/m/#!topic/golang-announce/65...
      - bsaul 6y ago
        except that the developer controls it, since its is embedded. As such it follows the exact same lifecycle as the code itself ( versionning, testing, etc).
        vips7L 6y ago
        This is misinformed. jlink has existed since jdk 11 and allows the developer to produce a custom JVM to ship with their application. jpackage also now exists to create installers for whatever platform your on. It is you the developer who are responsible for packaging your application correctly.
        6y ago
elric 6y ago
I don't know which JVMs are or aren't in Ubuntu. But Ubuntu 18 is over 2 years old. Almost every major linux distribution has stable, LTS versions of Java 8 and 11 -- which are the currently supported LTS versions in general. A package can easily add a dependency on a specific Java version. And unlike many other tools, if you have multiple versions of Java, all you usually need to do is add the right one to the $PATH. Sometimes you may have to set $JRE_HOME. And that's it. You're done. If that's too much of a pain to deal with, I hope you never have to install a tool that requires a specific PHP, Python or NodeJS version. I don't know of any serious tools written in Java that don't either explicitly say which version(s) are supported. Maybe some tools are poorly packaged. But again, that's not a problem with Java.
- apta 6y ago
  You can also ship the JVM directly with your product, that way it's system independent. Even better with jlink.