That's a good question - I don't know. But the trade-offs are different depending on whether you run your code yourself or your customers run it.
If you run your code yourself, you have full control over the deployment pipeline and jlink-ing your code and dependencies with JDK modules into a runnable artifact basically just moves infrastructure code around. You still have to define which Java version to run on and your a launch script and so on, but with jlink you can do that in the "Java realm", whereas with docker you do it the "Docker realm". Not a big difference, I would assume. (That said, jlink allows you to apply a few optimizations that reduce image size and slightly improve launch performance, but that's minor.)
If your customers run your code, jlink is an entirely different beast. With it, you deliver a runnable artifact that operates independently of any installed JRE (if there even is one). That's great because you can pick the exact Java version that you want to support and nobody can screw with that. Then again, it's also somewhat terrifying because customers can no longer independently update their Java version (well, they can, but your app doesn't care). That means if there's a security fix, you need to provide a new application image immediately. And that's like to come with an application update, too, so your customer better be prepared for that at any time.
I think there's a fair share of Java projects that can benefit from jlink, but how large that share is? Once again: no idea.
I don't write a lot of new Java applications in my current job, but I imagine that with the advent of containerized applications (using Docker, etc.) it's become important to keep the runtime as small as possible. If you want to deploy a separate runtime with each application, you want them to be LEAN.
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop