Hacker News Reader

Comment by koalaman | Hacker News Reader

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.

View on HN

Point 1 is taken care by fat jars and jlink.

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 :)

Not yet.

But I would argue that it would still be more mature than Jib, given that Java 9 is almost one year old.

With the planned removal of java webstart from java 11 onwards this september, you can expect jlink to become much more relevant.

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

That is what build servers are for.

waiting on build servers is still waiting

Not if they are doing continuous builds on regular intervals.

I guess waiting for building Docker images doesn't count then.

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.

I hadn't looked at:

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...).

Reply on news.ycombinator.com