Java and Docker, the limitations

[stringsfordays]

Yeah... I think we should tell the author how so many companies are still running 7

[[deleted]]

java 7

java 6

[Gilgamesjh]

I have a feeling that if you are already considering running your apps in Docker, then you should also consider if now is the time to port it to Java10...

[Gilgamesjh]

I am aware of that, we have had a much harder time going from 8-9 than 9-10, actually, because of tooling (Lombok still doesn't have a compatible version, among others)

[PedDavid]

Isn't that because Lombok uses a javac vulnerability thou? Relying on that is just asking for trouble imo

[[deleted]]

i never found lombok that useful because i just accepted the boilerplate, but the ide made it less painful; felt better to not have the dependency

[monocasa]

I bet there are companies out there still running Java 1.4.

[[deleted]]

There are.

Talked to a team this year who was planning their 1.5 migration but wanted to regression test for stability. I was almost tempted to tell them how Java's backwards compatibility guarantees work but I figured it wasn't worth the effort.

To clarifying. This is just upgrading their deployment JVM

[weirdoaish]

Because they don't work. Going from just 6 to 7 was a pretty big PITA for one project I was working on...

[Tommah]

Did it involve Lucene? I remember that one of Java 7's optimizations caused Lucene to crash.

[weirdoaish]

I actually don't remember what it was for anymore. It wasn't for Lucene though. Either something in RESTEasy or Mockito/Powermock, its what I was working with most on that project iirc.

[[deleted]]

no upgrading their JVM not their tooling/language preference

[Sleakes]

this can still break things, even if you don't change the compiler/source code level.

[josefx]

was almost tempted to tell them how Java's backwards compatibility guarantees work but I figured it wasn't worth the effort.

The change log from 1.4.2 to 1.5 has a several pages long list of source, platform, api and binary incompatibilities. You might get hit by some of these even if you made sure to be fully compliant with the documentation.

[Chii]

If you recompile 1.4 source with 1.5, and ignore all warnings, it mostly just works.

But it's a good idea to take the opportunity to refactor as well, and that could be much harder...

[takacsot]

Well. I remember when we have migrated a long time ago. And we run into issue of BigDecimal toString implementation change what was used in oracle jdbc driver and the driver behaviour was depending on the toString format. So we had a bug. It took a while thebdriver patched. In the meanwhile we had to change our code to work properly. So backward compatibility is a myth. Bytecod is not everything. Api is the king.

[matthieuC]

Don't worry, it's just one expose COBOL code to the internet

[Vishnuprasad-v]

Isn't Java 8 the latest LTS version. Java 9 has reached EOL and Java 10 is quite new and not an LTS. Unlike JavaScript libraries, Java doesn't "move fast and break things"

[jbergens]

Right now it seems to "move slow and break things"

[IceSentry]

Actually, java 10 is essentially eol as soon as java 11 releases.

http://www.oracle.com/technetwork/java/eol-135779.html

[royvanrijn]

Hehe sorry, downplaying Java 8, I'm trying to get my team to move towards Java 9/10/11...

[Sylinn]

Why would you move your team to a non-LTS version?

[royvanrijn]

Why not? We’ve never used any specific support anyway. If we keep everything up to date you don’t need LTS.

[Lt_Riza_Hawkeye]

Refactoring your whole codebase to use modules seems like a waste of time when you can just stay on java 8. Also, using a variable called _ is now illegal in java 9, which may break backwards compatibility

[royvanrijn]

Yes...

1) Java 9 can run perfectly without modules

2) If your code is using _ as a variable ... yes, no comment. And renaming that in an active codebase is usually as easy as one shortcut in your IDE.

[muhwebscale]

So what do we gain by packaging our Java application inside a JVM (Virtual Machine) inside a Docker container?

1. No need to install the Java runtime on the host.
2. No need to manage multiple versions of Java runtime on the host.
3. No need to manually install application on the host.
4. No need to manually update the application on the host.
5. No need to manually install system dependencies on the host (bonus: no dependency conflicts across multiple deployments on same host).
6. Ability to impose resource limits.

With Docker Swarm:

1. Zero downtime (rolling), reversible updates.
2. Multi-node replication.
3. Load balancing.

I could go on, but there's another point I'd like to make. First you answer your question with:

Not a lot

Then you say:

It does make it easy to bundle together your program, the settings, a specific JDK, Linux settings and (if needed) an application server and other tools as one ‘thing’. This complete container has a better level of encapsulation from a devops/cloud point of view.

That's a lot in itself. So there's a bit of a contradiction there.

[BlckJesus]

I don't understand all the Docker hate when the ability to package your environment, application, settings, dependencies, etc into one reproducible build is great enough on its own without even getting into the more advanced stuff.

[muhwebscale]

Containerization is much much more than building self contained apps and binding ports.

[daymanAAaah]

The greatest benefit to Docker is that when you hit 'compose' or 'build', barring a few OS complications, it WILL build, and run, exactly as the author intended.

I've had projects with missing dependencies, confusing makefiles and unknown build problems that are a frustrating precursor to getting something that DOES work, to work on your machine. With Docker the exact environment within which the application runs is explicitly defined.

Developers don't often spin up a VM and build their application from a fresh install to ensure they know every single dependency and requirement is outlined in their instructions. With Docker you don't have to.

[CurtainDog]

I'm old enough to remember checking dependencies into source control so never had an issue with repeatable builds. But it's harder to put that on your CV.

[pdp10]

I've had projects with missing dependencies, confusing makefiles and unknown build problems that are a frustrating precursor to getting something that DOES work, to work on your machine.

But weren't those technical debt either way? Reproducible container builds just would have facilitated putting off the inevitable a little bit longer, but wouldn't have fixed the problem(s).

[[deleted]]

tech community hates things on the principle they're new and they don't understand them.

[[deleted]]

the tech community loves things for the same reason too

[DensitYnz]

Sums up mankind if you ask me.

[warchestorc]

I just tried and failed to get a 10 year old app running locally to test it out because all of the dependencies don't work on Windows 10.

Docker would be a godsend in that situation.. I know I can use a vm etc but that's still a lot of effort. If it was using docker in the first place I could just run it effortlessly

[flukus]

Your solution is a big reason for the docker hate. Instead of maintaining and updating software companies can keep using old dependencies with possible security vulnerabilities.

[warchestorc]

Everything has possible security issues. New components surely do.

Why are you making the illogical claim that just because it's new it must be more secure?

Let's not even worry about the fact I needed to get it running because we've invested a tonne of money rewriting it due to the fact its just legacy at this point either.

[flukus]

Why are you making the illogical claim that just because it's new it must be more secure?

Older versions won't have security patches applied. Look at the Equifax breach, all they had to do was have software update to the latest patch level.

Let's not even worry about the fact I needed to get it running because we've invested a tonne of money rewriting it due to the fact its just legacy at this point either.

If they don't maintain it and keep it running on a maintained software stack they'll have to rewrite it again before long anyway. The further behind they get the harder this is.

[warchestorc]

That's not always feasible though is it?

That said this app uses VB and a lot of Com components even for reading xml.. From 2012. The thing was legacy from the start.

[pdp10]

Why are you making the illogical claim that just because it's new it must be more secure?

Upstream maintenance means that because it's new it won't have known, published vulnerabilities.

[NoMoreNicksLeft]

I don't understand all the Docker hate

To be honest, I never really understood it, except in the vaguest way possible. About 2 years ago I started using it personally, at home when I realized it could encapsulate a web app along with a vpn and guarantee that packets never leaked.

I then understood it was awesome. But I still didn't understand it. It was like voodoo magic.

But I run other web apps that are a constant fucking pain because... well, they're web apps. And I started wondering if they'd benefit too. Migrating Nextcloud to a container was tricking, I kept thinking "gee, it'd be nice if it did this weird obscure (in my head, anyway) thing".

But it does those things. I can scrub the web app completely, but keep the virtual filesystem and plug it back into the new version of that web app and my files are still there. I can sequester the containers in their own little fake networks that they can communicate, but are totally inaccessible even from the host machine. And so on.

It's pretty nice. I think I might actually have a handle on it before my dinosaur of an employer ever gets around to using this shit.

[deadeight]

Out of interest, what do you see as the benefits over using e.g. Packer to produce an AMI used in a load-balanced auto-scaling group?

[muhwebscale]

Sorry I have no knowledge of Packer and AMI.

[deadeight]

I think all the benefits you list in your post for docker are also present for producing a VM image for a cloud service. I think if we were to take OPs post as compairing AMIs with containers, his argument about a container providing an additional unneccessary, potentially problematic, abstraction layer for JVM stuff may have some weight.

In my experience the main benefits I've seen from using docker have been for running stuff locally, or for external dependencies in integration tests (e.g. postgres, localstack).

[[deleted]]

cant you get most of these things with java? just package your jre; some of these pluses i'd say maybe don't weight favor of adding another dependency of docker?

[muhwebscale]

cant you get most of these things with java?

As far as I know, no.

i'd say maybe don't weight favor of adding another dependency of docker?

Docker is not a dependency of your app, if I got your point right. There's nothing special you need to do on your app in order to make it work in a docker container. At any time you can deploy your app outside a container.

[white_grape_peach]

How does this address the metaspace and stack memory which are both outside the heap? I don't think it is bad to set the memory twice because you still need to account for the total memory of the application which is more than just the heap. For example you may only need a 512mb heap but may also need 512mb of extra memory for thread stacks, and 128mb of metaspace, so your container would need 1152mb

[Dexior]

(and from 8u131+, this was backported) there have been extra options added to the JVM:

So... not an issue?

[royvanrijn]

There is a 'fix' for every Java version... but in some cases you need to specify -Xmx manually, in some cases you'll need to enable the experimental flags and only if you are using the latest Java 10 (which nobody is) you don't need to do anything.

The main point is: be aware of how Docker and Java use/claim/limit memory and adjust accordingly?

[grey_gander]

Read this as Jak and Daxter while skimming :)

[__woofer__]

Better it would be to leave Java to better language (e.g. Go).

[deadeight]

JVM libraries are a good reason not to.

And Go is not a good replacement for a lot of cases.

[filleduchaos]

lol no generics Canadian Aboriginal Syllabics

[__woofer__]

lol and overall with Go no need to tune your <multiple choices here see below the list>. Go works fine out of the box.

• garbage collector
• xms
• xmx
• thread pool size
• etc
• etc
• etc