It actually does nowadays. The --platform flag integrates with QEMU. It's emulation so it's slower, but better than doing it manually.

[0] https://docs.docker.com/build/buildx/#build-multi-platform-i...

It does help, docker's buildkit backend (enabled when you use the buildx command instead of build) supports building for other architectures automatically. You can for example on an ARM device build a perfectly fine x86 or x64 image and push it to a registry, or vice-versa. It works by behind the scenes using QEMU to emulate the other architecture and binfmt_misc to run its executables. This all happens transparently and wraps up what used to be a bit of manual work and tweaking.

It also supports running other architecture images using the same QEMU magic. It's really quite polished and works well.

I like, how someone solves the OS issue and suddenly people start using different CPU archs.

Docker supports multi-platform builds, and many popular images have built in support for both architecture via their manifest. In my experience this only breaks in your own images where you download and install some package with a URL with a hardcoded architecture.

Docker does provide environment variables you can use to automatically download the right file depending on the target architecture, but the syntax is very cumbersome.

That said, yes using something on the JVM is much more convenient, but that’s not possible if you’re not using a JVM language.