4 ms·

There are really a host of reasons why it's a good idea. Off the top of my head here are three that I think justify the weight: 1. A Jar includes your app, but

There are really a host of reasons why it's a good idea. Off the top of my head here are three that I think justify the weight: 1. A Jar includes your app, but not your runtime or your applications native deps. Docker containers let you specify a whole lot more about your image that goes beyond the language specific application package. 2. You can use the same tooling and infrastructure for managing your executable binary artifacts across all the languages used in your org. 3. You can take advantage of cluster schedulers like K8s.

pjmlp 8y ago
Point 1 is taken care by fat jars and jlink.
- rbjorklin 8y ago
  While technically correct the maven-jlink-plugin is in alpha and I’ve not yet seen any application packaged this way. If you’re aware of any open-source project doing this I would be very interested :)
  - pjmlp 8y ago
    Not yet. But I would argue that it would still be more mature than Jib, given that Java 9 is almost one year old.
  - nomercy400 8y ago
    With the planned removal of java webstart from java 11 onwards this september, you can expect jlink to become much more relevant.
- dionian 8y ago
  For large projects, fat JARs are slow to build. Unless you bundle JARs inside the JAR and use a special classloader, like Spring Boot... I don't use them at all because it's a pain. Plus you'd probably want to put your app code that changes in a different layer if you're doing docker images, as opposed to the other 90% of your app which is dependencies that rarely change
  - pjmlp 8y ago
    That is what build servers are for.
    - dionian 8y ago
      waiting on build servers is still waiting
      - pjmlp 8y ago
        Not if they are doing continuous builds on regular intervals. I guess waiting for building Docker images doesn't count then.
  - i386 8y ago
    fat jars are just as expensive to create as war files. No matter which way you do this you’re going to be copying a lot of files around.
- e12e 8y ago
  I hadn't looked at: http://openjdk.java.net/jeps/201 http://openjdk.java.net/jeps/201 before - nor on the linked jep 220. I wasn't really aware project jigsaw and jdk 9/10 had quite so ambitious goals (paraphrasing:... Getting rid of the old and inefficient jar format based on zip file format...).

pjmlp 8y ago

Point 1 is taken care by fat jars and jlink.

rbjorklin 8y ago
While technically correct the maven-jlink-plugin is in alpha and I’ve not yet seen any application packaged this way. If you’re aware of any open-source project doing this I would be very interested :)
- pjmlp 8y ago
  Not yet. But I would argue that it would still be more mature than Jib, given that Java 9 is almost one year old.
- nomercy400 8y ago
  With the planned removal of java webstart from java 11 onwards this september, you can expect jlink to become much more relevant.
dionian 8y ago
For large projects, fat JARs are slow to build. Unless you bundle JARs inside the JAR and use a special classloader, like Spring Boot... I don't use them at all because it's a pain. Plus you'd probably want to put your app code that changes in a different layer if you're doing docker images, as opposed to the other 90% of your app which is dependencies that rarely change
- pjmlp 8y ago
  That is what build servers are for.
  - dionian 8y ago
    waiting on build servers is still waiting
    - pjmlp 8y ago
      Not if they are doing continuous builds on regular intervals. I guess waiting for building Docker images doesn't count then.
- i386 8y ago
  fat jars are just as expensive to create as war files. No matter which way you do this you’re going to be copying a lot of files around.
e12e 8y ago
I hadn't looked at: http://openjdk.java.net/jeps/201 http://openjdk.java.net/jeps/201 before - nor on the linked jep 220. I wasn't really aware project jigsaw and jdk 9/10 had quite so ambitious goals (paraphrasing:... Getting rid of the old and inefficient jar format based on zip file format...).