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.
But how is that related to the database? Wouldn't you just run the database in a container as a side car?
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.
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?
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.
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.
No we don't need them.
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.
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.
As opposed to my assertion: "a Java dev knows one of {gradle,maven,shell} is almost always true.
I have been coding since 1986.
There was a time before Docker.
This approach was way lighter weight than pushing enormous images around.
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.
> 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.
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.
Per the HN Guidelines:
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
It's not hard to imagine that using a big container solution designed for another operating system (and performance hit) is not the most elegant solution here. Especially when the alternative is an environment variable and zip file you already mentioned yourself. There is no step three.
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).