4 ms·

In the age of containers it's really not that much harder to build and deploy a JVM app. Edit: thanks for the downvotes but you could at least tell me what's s

In the age of containers it's really not that much harder to build and deploy a JVM app. Edit: thanks for the downvotes but you could at least tell me what's so crazy about my statement.

djsumdog 10y ago
There are still some licensing issues. For instance, Atlassian has an official docker container to evaluate Confluence, but they don't support it in production since it uses OpenJDK and Confluence is still somewhat broken on OpenJDK. Rather than fix Confluence to work on OpenJDK (I don't want to imagine what type of reflection garbage they've got going on down there that breaks so bad on OpenJDK), their instructions tell you how to make your own Dockerfile using the official Oracle runtime. Actually, in that situation, if it won't run on OracleJDK it's probably not going to work via a native compiler either.
whatnotests 10y ago
One app, sure. At work I'm running 17 different containers- many of which require their own JVM. (That's 3 different JRuby apps, zookeeper, kafka, and ElasticSearch.) Those JVMs get heavy when you're shipping container images compared to small Go or Rust binaries.
lmm 10y ago
To my mind the JVM is where containers make the least sense. If you build an executable jar you can run with "java -jar ..." then that seems just as simple as "docker run ..." and gets you the single-file deployment, and you can control memory allocation via flags if you need to. You don't get virtual networking but IME that doesn't add value in the first place.
therealmarv 10y ago
No downvote from me. But a explanation why e.g. compiled binaries are better. I had a hard time to get a normal non fancy Scala Play project running on a 512MB DigitalOcean instance. Mostly because it needs a lot more ram for building. I solved it with using a bigger swap partition. With single binary precompiled programs this problem is more a developer machine problem than a infrastructure problem. So I think the deployment step itself (and not looking at anything else) is easier with a small single binaries.
- lmm 10y ago
  You shouldn't build it on the deployment server. You build a jar and upload/download that to/from the place you want it to run, just as you'd do with an executable. A jar is "not binary" but what practical difference does that make?
  - therealmarv 10y ago
    yes, you're right, thanks for pointing that out.

In the age of containers it's really not that much harder to build and deploy a JVM app. Edit: thanks for the downvotes but you could at least tell me what's so crazy about my statement.

djsumdog 10y ago

There are still some licensing issues. For instance, Atlassian has an official docker container to evaluate Confluence, but they don't support it in production since it uses OpenJDK and Confluence is still somewhat broken on OpenJDK. Rather than fix Confluence to work on OpenJDK (I don't want to imagine what type of reflection garbage they've got going on down there that breaks so bad on OpenJDK), their instructions tell you how to make your own Dockerfile using the official Oracle runtime. Actually, in that situation, if it won't run on OracleJDK it's probably not going to work via a native compiler either.

whatnotests 10y ago

One app, sure. At work I'm running 17 different containers- many of which require their own JVM. (That's 3 different JRuby apps, zookeeper, kafka, and ElasticSearch.) Those JVMs get heavy when you're shipping container images compared to small Go or Rust binaries.

lmm 10y ago

To my mind the JVM is where containers make the least sense. If you build an executable jar you can run with "java -jar ..." then that seems just as simple as "docker run ..." and gets you the single-file deployment, and you can control memory allocation via flags if you need to. You don't get virtual networking but IME that doesn't add value in the first place.

therealmarv 10y ago

No downvote from me. But a explanation why e.g. compiled binaries are better. I had a hard time to get a normal non fancy Scala Play project running on a 512MB DigitalOcean instance. Mostly because it needs a lot more ram for building. I solved it with using a bigger swap partition. With single binary precompiled programs this problem is more a developer machine problem than a infrastructure problem. So I think the deployment step itself (and not looking at anything else) is easier with a small single binaries.

lmm 10y ago
You shouldn't build it on the deployment server. You build a jar and upload/download that to/from the place you want it to run, just as you'd do with an executable. A jar is "not binary" but what practical difference does that make?
- therealmarv 10y ago
  yes, you're right, thanks for pointing that out.