Hacker News Reader

Comment by skrebbel | Hacker News Reader

I'm a Docker noob and I haven't shipped Java in ten years, and I find that this article leaves the main question unanswered: what happened to just building a JAR?

When I read that sentence, I assumed that it must be something about controlling the JVM parameters and version, or the ability to include certain system tools or imagemagick type of CLI thingos, but then as the article goes on, I see none of that. None of the things that, to my uninitiated mind, give Docker an edge over building a plain old JAR.

So why? Why is it necessary / a good idea to Dockerize a Java app? Can anyone help me out?

View on HN

A jar needs deps. A fat jar still often needs a script to run it with baked-in parameters, JAVA_HOME/PATH manipulation, maybe a tanuki service wrapper, a cron job to keep it running, some what to bootstrap it from scratch (maven) - everything extremely specific to the java ecosystem. Docker can do some a lot of that stuff generically, then leveraging kubernetes you can get much more advanced deployments based on pods, labels, etc... at a much higher level, with a dashboard. Throw in Prometheus/ELK etc... then you have a centralized log store you can just read.

If your entire stack is a monolithic fat jar, this isn't the solution you are looking for.

> I find that this article leaves the main question unanswered: what happened to just building a JAR?

What happened is that the world has turned polyglot. Many of the things that Java pioneered in the wider industry have been resupplied in different places at different levels of the stack.

Containerisation essentially creates uniformity for a lot of workflows. While Java has addressed all these concerns itself for a long time, the overhead of two build chains, two admin toolkits, two registries etc etc becomes increasingly onerous.

Some folks will have a 100% Java mandate. This project is not for them.

Others will have a 100% containers mandate. This project is for them.

We have a custom service that requires a Java jar that plugs into an application server. Our partner org only supports this on CentOS/Fedora/RedHat.

This also talks to another service, which is an Apache binary plugin provided by another partner org who once again only supports CentOS/Fedora/RedHat. This Apache plugin not only requires Apache, but it has to sit on top of a properly configured Fuse file system. For extra fun, we have to run 4 copies of this Apache server with 4 different license keys which are all hard-coded to the same damn file on the file system (thanks assholes).

This application server sits behind an Nginx proxy for a variety of annoying reasons (routing, rewriting response output, security stuff, etc.). We also package it up with a Python server that does some additional delegated work depending on the type of request.

Oh, and we run all of the rest of our infrastructure on Ubuntu.

All these different pieces work together to provide a "single" service. None of them make any sense on their own.

We wrap up all these services and deploy them as a unit. We deploy them to a couple servers behind a load balancer. There's no point breaking them out into separate layers on different servers, we'd just be wasting computation resources as this system sits idle most of the day. We pack them in as tightly as we can manage given the above constraints.

There's some consolidation we could potentially do, i.e. we could do some of the routing in Apache thus removing our dependency on Nginx, but uh, we use Nginx everywhere else.

We could remove the Python piece, write it as another Java jar and plug it into the application server, but again, most of our other stuff is in Python.

This is the kind of stuff where Docker is really useful. It gives us a uniform interface to all of these different pieces. It gives us centralized logging, resource control, process management, service dependency management, isolation (4 instances of Apache with their 4 damn license keys in the same location but isolated form each other), deployment, etc.

If you don't have these kinds of problems, then you might not need Docker. If you do have these kinds of problems, Docker is a life saver.

Do I like that it's this way? No. But this is the reality of the business we are in and we have to accommodate the needs of our biggest customers otherwise we can't pay the bills.

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.

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

For one I’ve found that Docker containers provide some teachable moments for people trying to learn (or who should already know better) about the CI/CD pipeline.

Docker images take away a lot of wishful thinking. Some people will, at least occasionally, refuse to take responsibility for a problem until you can demo it for them locally. If you can’t demo a problem locally you’re already in a world of pain.

Call it a good fence for good neighbors, if that works for you.

You still build the jar and then you wrap that in a docker image so it can be deployed in a standard way just like all other (non java) services in the cluster.

Assuming you run container infrastructure like Kubernetes or Mesos or what have you

If all you deploy are fat jars to a few nodes, this is overkill and will increase complexity for no good reason. Yet, I predict that most K8S deployments fall into this range. If your devs are bored and want $tech to play with, at list this won't be as damaging as introducing an overly complicated programming language or something.

Fo heterogenous deployments and with a lot of nodes, this standardizes everything and thus reduces complexity, instead of increasing it without adding any value.

    at list this won't be as damaging as introducing an overly complicated programming language or something.

As a 15 year veteran of the Java salt mines, this made me chuckle.

The publication of the J2EE 1.0 spec left me feeling queasy. If I had known instead of just suspected what this meant for the next ten years Rube Goldberg would rule Java, I might have made different choices.

I don’t think it’s an accident that the two projects I’m proudest of were an embedded and a mobile Java app.

Every generations got its own disease.

In particular, if the use-case calls for all dependencies to be bundled together, then why not an uberjar? Why use something as wonky as Docker when the JVM eco-system offers a solution that has been solid and mature for 15 years?

As to my use of "wonky", see some of the frustrations at the end of "Docker protects a programming paradigm that we should get rid of":

http://www.smashcompany.com/technology/docker-protects-a-pro...

It's about having a closer integration (i.e. beyond dropping a fat jar in a Docker) between the Java toolchain and Docker toolchain.

Why? Because when you need to operationalize stuff, you suddenly or less suddenly and more painfully discover a tons of other concerns not directly tied to the actual Java build.

Dependencies outside of uberjar (like JVM, glibc etc.), speed of builds (through incremental builds) and potentially size of the final artifact.

This is a tool that helps with Docker images. If you don't need a Docker image, you clearly don't need it. If the question is why Docker images or why containers, then the answer is not in the docs for this tools.

> what happened to just building a JAR?

Same thing that happened to rsyncing an executable. Every application has _something_ specific to the environment eventually.

To be fair, Docker is not somehow magic. It's "_something_" is a Linux kernel + Docker daemon. That's just a rather small/common dependency.

To actually have no "_something_", you need unikernels.

> what happened to just building a JAR

(1) JARs don't have native code (unless you package that in an extract it at runtime)

(2) JARs don't have the Java runtime (unless you package that in to an executable and extract it at runtime)

(3) JARs can't be easily isolated or managed, at least not to the extent of Docker

jar still needs a java binary

and which java version does it need?

who wants to install and maintain different java versions? Not me. So users provided a docker and I can run that whatever it is.

sometimes an application also need some locales, timezone data, etc.

Ecause you can hide you're running a old and unsecure version (some EE software work still with Java 1.6)

It's not necessary. The simplest thing to do is to build a fat jar.

Shinny new toys syndrome.

A plain JEE container is more than enough for like 99% of use cases.

And starting with Java 9, you can even link everything together VM + fat jar.

> A plain JEE container is more than enough for like 99% of use cases.

Odd, I would say that a JEE container is too much for like 99% of use cases :).

(Point being that most of the time these days all I seem to need is an embeddable HTTP server and a main() function. Yet I see people insisting on incredibly complex JEE container deployments rather than just a simple "java myserver.jar".)

Usually JEE containers get to be shared.

Of course, I am not advocating a JEE container for a doing a single REST point or website.

You cant simply deploy a plain JAR to ECR, K8S (EKS/AKS/GKE), or OpenShift, or any other such system. And organizations/people are increasingly using such tools/services for building their services.

Reply on news.ycombinator.com