5 ms·

I doubt they would have been satisfied with the mechanism Packr uses. Packr distributes a static copy of a JVM with every build, which results in some less-than

I doubt they would have been satisfied with the mechanism Packr uses. Packr distributes a static copy of a JVM with every build, which results in some less-than-desirable side effects: - The more apps you've obtained this way, the more copies of JVMs you have on your hard drive. - These per-app JVMs aren't getting patched when the mainline JRE does. In a lot of ways, this undermines the purpose of the way Java is structured. If you're going to be statically compiling your product, why not use a more suitable platform?

deleted 12y ago
[deleted]
stingraycharles 12y ago
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?
- mbreese 12y ago
  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.
  - BHSPitMonkey 12y ago
    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.
dleskov 12y ago
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.
chii 12y ago
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.
- BHSPitMonkey 12y ago
  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.

deleted 12y ago

[deleted]

stingraycharles 12y ago

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?

mbreese 12y ago
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.
- BHSPitMonkey 12y ago
  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.

dleskov 12y ago

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.

chii 12y ago

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.

BHSPitMonkey 12y ago
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.