Java in a docker container

[kant kodali]

https://www.quora.com/Why-is-LinkedIn-getting-rid-of-Scala
https://www.quora.com/Is-Twitter-getting-rid-of-Scala

This is great however we still need to watch out on Go.



On Thu, Dec 15, 2016 at 11:43 AM, John Rose <john.r.rose at oracle.com> wrote:

> On Dec 15, 2016, at 1:45 AM, Volker Simonis <volker.simonis at gmail.com>
> wrote:
>
>
> I think these are the reasons why other scripting or VM-based
> languages run better "by default" in container enviroments - they
> simple need fewer resources by default. But I think Java can be tuned
> in the same way - we just have to do it :)
>
>
> Thanks, Volker; that's a good summary of our startup issues.
>
> The CDS and AOT work are examples of our efforts to address these them.
>
> In general, there is more to do in the direction of offloading startup
> work to configuration time.
>
> (Relatedly, warmup work and resource sharing are also works in progress.)
>
> Meanwhile, container-based computing uses lots of "glue" logic, and lots
> of it is in the form of short-run shell script calls which execute in
> vanilla execution environments.
>
> Lightweight runtimes have the advantage of low startup (and teardown)
> overhead for such script-like calls.
>
> Such runtimes are easy to choose for those jobs, and then they stick
> around for any bigger, longer-running jobs, such as monitoring software.
>
> I think, for the bigger jobs, a bulletproof VM like Java's is preferable,
> but the lightweight ones are already on the job, because they were there on
> the thin end of the wedge.
>
> I expect we can continue to make the JVM more and more useful at the same
> thin end of the wedge.
>
> The general themes here are offloading startup work (metadata load, JIT,
> heap filling) and increased sharing of static resources.
>
> — John
>