
Improved Docker Container Integration with Java 10 - el_duderino
https://blog.docker.com/2018/04/improved-docker-container-integration-with-java-10/
======
rhacker
I can't seem to upgrade to Java 9 still. Its the module system. Waiting for
open source to catch up in some situations. See one of the problems is that
the way Java is started needs to change to enable JAXB. But many open source
products have lots of code that start Java processes, and never use that
command line. Did this change in Java 10, did they bring back JAXB so things
will start again?

~~~
SanderMak
Nope. In fact the module containing JAXB (and 5 other EE technologies) have
been deprecated and will be removed in Java 11. So indeed, you can use the
`--add-modules java.xml.bind` workaround, but it will break with Java 11. The
real solution is to add a JAXB implementation of your choice as dependency to
the application.

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

------
chenzhekl
Could anyone point me to the advantages of running Java inside a Docker
container? It seems to be VM in VM. Why do we need the extra redirection?

~~~
joeskyyy
A container is not a VM (at least in the traditional sense). The advantages of
running java inside of a container is that you can ship all of your things as
one artifact, and run it on a bunch of different infrastructures, with all
it's dependencies packaged together. So rather than needing to use something
to ensure your properties are configured correctly, and all your passwords are
where they need to be, and all your other bits and such are in place, you can
pack it all in a container and run it anywhere (Well... "anywhere" being a bit
of a stretch, but you get the idea haha)

~~~
delecti
So Java, which was supposed to be "write once, run anywhere", didn't meet that
goal enough, so Docker wraps it in something that "actually for real" is
supposed to be "write once, run anywhere", but even then doesn't quite meet
that goal?

~~~
crazysmoove
No. Java's "write once, run anywhere" promise is that you would not have to
re-compile your source code to target different architectures like you do with
C or C++. Docker's promise is that you don't have to rely on external things
like databases, filesystem details, and other things _outside your program_
being in place across environments. Same idea, different levels of
abstraction.

------
e12e
Is it me or does it seem odd that docker community edition is left out? And
isn't adding an additional "silent c is for container" in front of cgroups a
bit... Much?

I mean, if java 10 recognises cgroup limits, that should work under things
like systemd and all container runtimes?

~~~
sofaofthedamned
I can't see how it's EE only. It reads the appropriate bits to work out the
memory available, can't see how CE would hide that.

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.

~~~
e12e
Hm, I wonder if this might possibly be related to an issue I've seen in
production with docker - of a container being killed by the oom killer... But
only on server boot.

~~~
sofaofthedamned
Maybe. We've had serious problems with this, mostly with mongodb but other
stuff as well.Java 10 is making an effort to fix this but I hate Java, and
really it's a kernel/userland linux issue as you can't expect software not to
request cache memory that it doesn't know exists.

------
chris_wot
Genuine question: how many startups are using Java now? is this dealing with
older sites that are stuck with Java on the server, or are there genuinely
many new deployments of Java-based systems out there?

~~~
ganonm
I am at an early stage startup which is using Java (and Kotlin) on the server-
side. There are various reasons for this, most of them pragmatic, but also
some technical ones. Pragmatic reasons:

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

~~~
chris_wot
I think people must think I hate Java. I don’t. I think it’s great and I love
Spring, though I have been mostly programming in C++ so haven’t touched Java
in a long while personally.

I’m more concerned with the copyright status of Java APIs. Can you really be
sure that you will be safe from Oracle’s clutches?

~~~
maltalex
> I’m more concerned with the copyright status of Java APIs

Building something using OpenJDK using Java APIs shouldn't get you in any
trouble.

What got Google in trouble with Oracle was that they copied and re-implemented
all of Java's APIs. Are you planning on doing something similar?

~~~
chris_wot
Funny, the WINE project does this.

~~~
maltalex
So does ReactOS.

Only both projects are pretty pointless to sue since they aren't making any
money.

