Improved Docker Container Integration with Java 10 (blog.docker.com)

Recently we have started a migration of our pipeline to Kubernetes, so these improvements are a real benefit to our use case.

edit: sorry I mean other than startups you'll find plenty.

We're also moving ahead with our plan to replace node with the jvm for our backend.

In fact, I recently had to create a cross-platform desktop app, and I'm still not aware of a better option then the JVM. I would have preferred to write it in Scala, but opted for Java to make it easier for the rest of the team to maintain.

Java isn't an awesome language, but it's fine. There's a lot of awful legacy Java code out in the wild, and I wouldn't want to work on it. But Java as a language is boring, inoffensive, and it works. As a result, it's probably going to be around for a long time.

- Many engineers know Java to at least an intermediate level, so they can be productive quicker (and hiring is easier)

- We had some existing libraries written in Java, so integrating them with the web platform was much easier if we went down the JVM route

- Java is the language most familiar to members of the startup (including me, although I also have experience in RoR, Kotlin, ObjectiveC and JavaScript)

Technical:

- Java is generally very performant and running on the JVM means we don't generally have to worry about platform specific issues (there are well known exceptions of course e.g. file path issues)

- The language itself is at a reasonable level of abstraction. It is strongly typed and IMO, writing a non-trivial backend in a dynamically typed language is a sub-optimal choice. It has a huge ecosystem of robust, battle tested libraries that are indispensable to us (e.g. JGraphT). There is a huge community - you are unlikely to run into 'uncharted' territory

- It is popular to hate on Java but it really isn't that bad a language, especially if you aim to follow guidelines like those in Effective Java (probably my favourite programming book) e.g. avoiding mutable state and side-effects. It will never be as good as a modern language like Kotlin (data classes are my favourite feature there), but it is good enough

- The server frameworks available are seriously robust and 'just work'

- There is always the option of using alternative JVM languages (we use Kotlin for a large part of the backend)

In summary, we are 6 months into developing the web platform, progress is rapid, and we have no regrets (yet) about the technology choices. IMO, sometimes boring is best.

Java is absolutely huge in the corporate world, where they build new projects with it all the time.

Quite a few. It's a solid choice for a startup for a variety of reasons:

- The Java (and more generally, the JVM) ecosystem is huge and includes stable, performant libraries and frameworks for just about every use case you can have. No need to re-invent the wheel.

- Java as a language is mature and performant, but is still actively being improved.

- No vendor lock-in. There are multiple implementations of everything including the JVM itself (unlike C# for example).

- There are very good tools for developing, debugging and profiling JVM applications.

- Some of the most popular big-data related tools are all based on the JVM. Just to name a few - Kafka (Scala), Hadoop (Java), Cassandra (Java), Spark (Scala), Ignite (Java), Elasticsearch (Java), Storm (Clojure), Neo4j (Java) and many more. So even if you're not using Java, you're probably using Java.

- Android apps are JVM-based. So every startup with a native android app is writing Java (or Kotlin).

- Hiring Java developers is easy(er). Everyone knows Java. Want to hire a junior developer? No problem. Want a veteran with 20 years of Jave experience? You can find those too.

- Java is well supported - due to its popularity, vendors usually offer first class SDKs and support for Java developers.

- There are many JVM-based languages. Don't like Java? No problem - you can use Clojure, Kotlin, Groovy, Scala, JRuby or even Jython. Some of them are even directly compatible with Java (and/or each other) so you can mix and match in some cases.

http://esotericsoftware.com

(disclaimer: I'm author of the O'Reilly book Java 9 Modularity (see https://javamodularity.com) which discusses this and other migration issues in great detail)

        <dependency>                                                            
            <groupId>org.glassfish.jaxb</groupId>                                                                                                                            
            <artifactId>jaxb-runtime</artifactId>                               
            <version>2.3.0</version>                                            
        </dependency>                                                           
        <dependency>                                                            
            <groupId>org.glassfish.jaxb</groupId>                               
            <artifactId>jaxb-core</artifactId>                                  
            <version>2.3.0</version>                                            
        </dependency>                                                           
        <dependency>                                                            
            <groupId>javax.xml.bind</groupId>                                   
            <artifactId>jaxb-api</artifactId>                                   
            <version>2.3.0</version>                                            
        </dependency> 

And BTW, I would skip Java 9 and go straight to Java 10 now.

So you can see it as a convenient way to distribute the JVM. Say that the JVM makes your application portable wrt the OS, Docker makes the JVM itself more portable.

A VM is also super heavy: all those libraries, the package system, init/systemd and you need some Ansible/Chef/Puppet scripts to build all that. A container still has a lot of those libraries (most are build on a base distro image: ubuntu, debian, alpine, etc), but no init/systemd. Your process runs as 1 with cgroups used for isolation.

You also have this nice contained artifact. No packaging it as an RPM/DEB and having to install it. It comes with its JVM and dependencies in there. It will always run the same way where ever you put it. If you have five containers that all package the same way, when you deploy, you don't get 5x the space usage. Docker uses overlay filesystems so the base can be shared.

Also once it's in a container, you can use something fancy like Marathon, K8s, nomad or swarm to schedule it to run somewhere out on a cluster. These ecosystems have tools for monitoring the number of services you have running in parallel and the ability to scale them up and down.

You don't get the isolation/security you get in a VM (if the kernel has an exploit, it can be exploited from within the container. It shares the host's kernel), but they are as light as a process with some security guarantees via cgroups and with all your artifacts and dependencies packed into an image you can easily save off, transfer and deploy.

And, as other people have pointed out, a docker container isn't a VM. It's a chroot process with a bunch of tooling around provisioning, networking, security, etc around it.

One of the big wins of docker is that it allows you to ship file-systems around and run them as if they were binaries.

1. A compatible JVM is installed somewhere.

2. When you run your application, it uses that JVM and not some other JVM.

3. You have the right flags passed to the JVM. For example, max heap size matching your application's actual usage, garbage collector tuning, thread stack size, and any properties that are set via -D.

4. Your jar file is there.

5. There is a place to write log files, and your application's logging system knows to write them there.

6. If you are using any native libraries through JNI, they need to be installed, and the JVM must be able to find them and use them.

7. If you listen on port, an available port number is found, your application knows what it is, and the rest of the world knows where to find you.

I believe Docker addresses all these points.

The problem is wider than Java anyways. Containers see the system free memory, not what's available to that container regardless of the cgroup constraints. We've hit this many times and sometimes workarounds are available (mongodb) but sometimes they're not and in our k8s environment this means some pods will restart constantly when they try to cache over and above what their cgroup allows.

The real fix is to tell a container not the system free memory but that which it's been allowed to use - afaik this is really difficult to implement, which is why the kernel hasn't had this done yet.

EDIT: obvs the container could read the cgroup limits (which I assume is what Java 10 does) but all the userland tools would have to be changed as well as some kernel functions.