Most of the Java security issues only affected applets, not standalone apps. And the larger and the more sophisticated a standalone app is, the less desirable is running it on the system-default JRE.

You can easily distribute the JRE, but also autodetect if there is an existing JRE installation, and use that instead.

Packaging a jvm is the right move for consumer apps. It's lower friction for people downloading and using it, and harddrive space these days are dirt cheap.

In that case, why not just have your installer check if Java is installed, and install a shared JRE if it's not? This is the case with most .NET applications I've had to install on Windows.

So in essence you're saying that if I want the advantages of static linking, I shouldn't be using java? Isn't there a middle ground somewhere?

You have the same advantages and disadvantages with static-linking in general. If you want an easily distributable application (non-enterprise), then I think something like this is a great middle ground.

The biggest attack surface for Java is from the web, so that should limit the disadvantages of embedding a JVM. So long as you aren't using your embedded JVM to load external code, you should be okay.

The difference between this being that normally you're only linking specific libraries that you need, instead of an entire runtime and standard library. There's a lot of potential energy hiding in each of these packages.