Java is an outlier here. For most languages the process of dockerizing a codebase involves learning a separate tool (Docker). As someone who knows Docker, I get the temptation to say "who cares, just write a few lines of Dockerfile", but after talking to a bunch of developers about our container-based tool, having to leave their toolchain to build an image is a bigger sticking point than you might think.

But this is begging the question. If the work was more integrated with the compiler, it would still need to be learned. If your compiler of choice spit out an deployable unit akin to an image you'd still need something akin to the Dockerfile to specify exposed ports and volumes and such, no?

The Dockerfile doesn't specify volumes, those are configured at runtime. In the case of Kubernetes, they're configured in the pod spec.

As for ports, EXPOSE in a Dockerfile is basically just documentation/metadata. In practice ports are exposed at runtime (if using docker) or by configuring services (if using Kubernetes), and these are unaffected by whether a port is exposed in the dockerfile.

IMHO this is how it should be -- if I'm running a containerized database or web server, I want to be able to specify the port that the rest of the world sees it as, I don't want the container creator to decide that.

while I admit I'm being a little loose in what would translate where in this hypothetical, none of it seems so easily cut out.