[pjmlp]

Here is the thing, maybe you don't need Docker to use Java, which was invented exactly to abstract the underlying OS and CPU architecture (and isn't the only one at that game).

Even worse, given that Docker and Kubernetes basically take Java/.NET application servers to other programming languages.

Talk about fitting square pegs into round holes.

[yusefnapora]

It's not so much about the Java code itself. When your Java app needs to talk to a database, it's convenient to be able to write integration tests against a running instance of the real DB. Ideally you'd also have a light-weight mock DB for unit tests, but some things only show up against the real deal. I guess you _could_ build that kind of test environment without containers, but I sure wouldn't want to.

[nicoburns]

If you're using an open source database like MySQL or Postgres it's pretty trivial to do this without containers. All you need is ~10 lines of SQL to create a new database and database user on your single local database instance. I don't understand why anyone would use a different database for testing and production. As far as I'm concerned, Postgres/MySQL are lightweight. I certainly have them running permanently on my machine and they use almost no resources when not in active use.

[brimble]

Now you need to git-bisect. And the range includes versions that ran in production with three different versions of your DB daemon (MySQL, PostgreSQL, whatever). The version might matter—in fact, look at that, the oldest few commits error on the current version of the DB.

Or you need to try something on another project that uses a different version of your database server. Or you need to pinch-hit on a project that has a half-dozen service dependencies at particular versions, none of which you have installed and running already.

The ability to very easily spin up clean installs of a bunch of services at arbitrary versions is incredibly useful. Containers aren't the only way to do that, but Docker does make it pretty damn convenient.

[dewey]

> It's not so much about the Java code itself.

But how is that related to the database? Wouldn't you just run the database in a container as a side car?

[fulafel]

IO in the Mac "Docker Desktop" app (which wraps a Linux VM and a virtualization framework) is quite slow even on x86 so people often run eg PostgreSQL as a native app.

[dewey]

Used to be!

https://www.docker.com/blog/speed-boost-achievement-unlocked...

[pjmlp]

That is what JDBC and JNDI are for.

[didip]

I have to hard disagree here. Plenty of Maven projects build are not immutable. They are buggy and not reliable when producing artifacts.

Also, Java 9 broke backward compatibility promise, and Java 17 broke it further by disabling a lot of default modules. Docker helps A/B testing multiple variation of JDK for our builds.

We definitely need Docker. It's a live saver for so many of our Java projects.

Not to mention, every single CI/CD engineers in a big company will mandate Docker as a packaging requirement anyway. So why not do it right and use Docker anyway?

[nicoburns]

> Also, Java 9 broke backward compatibility promise, and Java 17 broke it further by disabling a lot of default modules. Docker helps A/B testing multiple variation of JDK for our builds.

Does Java not have a version manager that lets you install multiple JDKs side-by-side and easily switch between them? For ecosystems I'm familiar with like Node.js and Rust this as is simple as a single command to install a given version and adding a text file with the required version to each repository(/directory) (it then gets used automatically when running code in that repo).

The answer for why not use Docker for development if you're using in production (on Windows/macOS) is that it's much slower. So the same reason that I have separate debug (fast compile time) and release (optimised) builds. If you're on Linux then Docker is great.

[didip]

Yes, in development mode, we use jenv: https://www.jenv.be/, that's how developers can switch between JDK.

But often times, our laptop don't have enough memory to perform the build and various tests. So we have to offload that to the CI/CD pipelines.

[carimura]

sdkman.io

[pjmlp]

I used containers, before many Docker advocates were out of kindergarten, starting with HP-UX Vault.

No we don't need them.

[paxys]

This almost always falls apart when you are developing two projects with conflicting stacks simultaneously. Can I run two JVMs with different versions and configurations? Multiple MySQL servers? Multiple web servers? And if I make a change to any one of them, how do I roll it out to my entire dev team? What would take endless tinkering becomes trivial with one Docker script.

[RandyRanderson]

Answers to your questions:

Yes, Yes, Yes, often teams use shells script, gradle or maven.

The same config you'd put in the docker yaml or whatever would go into the maven or whatever config except that the devs would be familiar with the existing tools and wouldn't spend countless hours mucking about with docker files.

Also unless you're using docker on x86 AND linux, likely things will not work or at least you'll run into mem, or perf or other compat issues.

After working with Java/Python for years, I had forgotten about the hell people go through with other langs deploying on diverse OSes/arches.

[paxys]

Well my argument is the exact opposite – if I know Docker why would I spend countless hours individually mucking about with maven and jvm and whatever dozens of custom components the service uses that I might not even know of? And repeat that for every other stack.

If I need to test my code locally against a service some other team develops, the only exchange needs to be "here's a docker compose file you can run with one command", not a wiki with shell scripts and other dozens of instructions which were likely outdated 3 years ago.

[RandyRanderson]

I understand your point. The article is about Java dev from a Java dev's perspective so your assertion "if I know Docker" is often not true for this class.

As opposed to my assertion: "a Java dev knows one of {gradle,maven,shell} is almost always true.

[pjmlp]

Yes, you can.

I have been coding since 1986.

There was a time before Docker.

[yoden]

Yeah, it's hilarious to see Docker so misused. Most Java/.Net environments will just work on any system without Docker. Adding Docker gives you a bunch of native platform and emulation pains you wouldn't have otherwise.

[vbezhenar]

You don’t “need” docker at all. But it makes things easier. You can build any application as a self-contained executable or directory with executable and related files. But it turned out it was not enough.

[pjmlp]

In 99% of the cases a EAR file + JDBC connection is enough.

[vbezhenar]

Imagine keycloak. It's classical enterprise Java application with database. You can deploy it as WAR file with configured JDBC connection.

But people who use keycloak often have little idea what Java is. They write code in Go and call Keycloak interfaces via REST API. They just need to start that thing and connect to some database.

With docker they'll get it up and running in minutes.

With EAR they'll spend next few days I bet it.

[sixbrx]

That leaves the whole setup of the application server that the EAR file needs out of the picture though. That stuff is not specified declaritively anywhere in the EAR, so it's just a wildcard that can make your application work or not work depending on version and configuration.

[smrtinsert]

Are you trolling? The last time I heard EAR files mentioned was 10 years ago.

[pjmlp]

Apparently those advocating stuff like Docker for OS agnostic languages never saw them in first place, probably busy in kindergarten and now pushing for Docker + WASM instead, 10 years later.

[icedchai]

Yep. The last company I was at was a Java shop. We had no need for containers. We built a fat jar for each "service." A deploy was little more than copying that fat jar + configuration file over. Multiple services easily ran without Docker.

This approach was way lighter weight than pushing enormous images around.

[otterley]

To get the best performance, many Java applications, especially network-intensive ones, use native libraries. Netty is a perfect example, and is used by a lot of projects.

> Even worse, given that Docker and Kubernetes basically take Java/.NET application servers to other programming languages.

No they don’t. Not sure what you intended to convey here.

[yoden]

Many (basically all?) Java libraries that use native code have pre-compiled code for all platforms. They'll just work on all platforms.

We've been upgrading our dependencies for arm64 support; for the most part it is as simple as updating our pined version to a newer version of the jar. Sometimes the native code is in a separate jar so you just add it (opencv works this way).

[pjmlp]

Package them inside of shared libraries of the Application container, or use a multitarget JAR/WAR/EAR file.

[otterley]

OK. The next problem is, what if you have a bunch of different apps that require different JVMs, potentially at different versions, and you want to run them all on the same box? You can do this with JAVA_HOME, but running them in containers is a lot more convenient, and safer, because you can ship the runtime with the app. As a developer, you also don’t have to concern yourself with whether the target machine already has the correct JVM installed, and update it yourself if you like, without waiting on someone else to do it for you.

[cmckn]

You also get the practical benefits of containers such as a convenient distribution mechanism that is language agnostic (a container registry) and abstracted management of network config like port bindings.

You’ll always be able to build a unique deployment solution for Java, python, or a native binary. But containers let you solve this problem the same way for every program.

[pjmlp]

Convenient only when one doesn't know better.

[otterley]

If you think you know better, why don't you give everyone a useful, detailed solution, instead of providing curt, unsubstantive, and argumentative responses?

Per the HN Guidelines:

"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."

[digisign]

The technology is well established now. I've noticed a similar kind of solution in the Python community, swatting flies with sledgehammers becomes the norm because modern machines can often take it. Until they can't.

[pjmlp]

Plenty of documentation and books available from decades of software development before Docker became a thing, no need to repeat them.