Java8 on windows runs on Java 11

[shannah]

Currently there is a problem with Java 8 on windows. If an app specifies javaVerson=8, then it will actually run on Java 11.

The reason is because there is a "worse" bug with Java 8 on windows that is causing the app to fail to launch.

E.g.

$ ./MyApp.exe
Error: opening registry key 'Software\JavaSoft\Java Runtime Environment'
Error: could not find java.dll
Error: Could not find Java SE Runtime Environment.

Now, this works fine before the launcher has the app.xml appended. Not sure which of those is the actual problem.

Need to investigate 3 possible areas:

1. zulu-8 distribution. (since it works fine with zulu-11+)
2. The parsing of the app.xml data at the end of the executble. As removing this and just providing (a different) app.xml beside the exe works.
3. The attributes of the app.xml data at the end of the executable. Perhaps its the specific atts ... need to pull them out to take a look.

[reportmill]

Is this for Java 8 on Windows 'any' or just for ARM? I wonder if it has to do with the change in numbering scheme, because Java 8 was really 'Java 1.8' under the covers.

[shannah]

This is Java 8 on all windows. Not just ARM.

Found the issue.

https://github.com/keerath/openjdk-8-source/blob/5f6e9d42a9f6b6736100c9c6f43f5f5ea1570cfb/jdk/src/windows/bin/java_md.c#L304-L333

https://github.com/keerath/openjdk-8-source/blob/5f6e9d42a9f6b6736100c9c6f43f5f5ea1570cfb/jdk/src/windows/bin/java_md.c#L438-L497

In OpenJDK 8, the windows bootstrap uses global registry keys to locate Java Home. It doesn't use the JAVA_HOME environment variable or the path. On other environments, jDeploy is able to just set the environment variable before creating the VM environment. On Java 8, however, it just ignores this.

Looks like it will look for a java.dll located in the same directory as the exe file, but I don't think this will be helpful in jDeploy's case.

I can think of two solutions to support Java 8 on windows.

1. The installer could add these registry keys. That isn't great because the installer would have to run with elevated permissions, as the registry key is in HK_LOCAL_MACHINE (not the CURRENT_USER). Not the end of the world, since many app installers require admin permissions on windows.

2. Have the installer make a copy of the JRE for each app that it installs.

These could be done for Java8/Windows only, since that seems to be the only platform combination that is affected. Java 11+ windows works fine, and Java8 linux/mac work fine.

[reportmill]

Either sounds good to me. I hardly have any users of SnapCode (unfortunately). It doesn't help that I'm stuck on Java 8, but I'm not sure the CheerpJ folks have much financial incentive to accelerate their Java 11+ schedule.

[reportmill]

I forgot to say thanks for taking the time to look into this. In my opinion, JDeploy is the only thing that makes Java desktop viable. Much better than Java WebStart was. :-)

[shannah]

Finally have something working. Will have a release tomorrow with the fix.

Solution was to use a dedicated jre for java 8 on windows. This required a slightly different file layout in the app directory but this is transparent to the user and developer.

no changes should be required. You'll just need to reinstall the app.

Dedicated jre support is something i planned on adding anyway. so this groundwork will be helpful for when I add that as a feature. (right now it isn't a specific feature.. is just used for java 8 on windows)

[reportmill]

Very nice, thank you!

[shannah]

Took a little longer to get this release out because Github retired some of the runners I was using for builds, so I had to perform some CI/CD surgery. But it is now released in v4.0.49.

You just need to download and run the installer for your app again.

Seemed to be working okay for me on Windows 11.

[reportmill]

Thanks Steve! This works for me as well now!

Though I forgot how bad Java 8 is with "HiDPI" screens. I have to manually set the "Override HiDPI scaling behavior" to get normal sized windows. And the text rendering is very wacky for some reason. But this will get me by until the CheerpJ folks get Java 11+ out. :-)

[shannah]

oh, maybe there's something I can do about that in the launcher.

[shannah]

This SO thread talks about this.

https://superuser.com/questions/988379/how-do-i-run-java-apps-upscaled-on-a-high-dpi-display

Seems in Java 8, swing advertises that it is dpi aware, but is not so windows doesn't override it. And unfortunately java 8 provided no way to override this. This was fixed in java 9.

It suggests that a solution is to add a manifest to the exe. I'll look into that.

[reportmill]

Thanks - that would be useful. I was looking at exactly that link this morning.

[shannah]

I managed to get the dpi scaling behaviour working "correctly" with Java 8 on Windows now. Will release it in the next update - maybe tomorrow.

As you said, it is still a little burry, and the text is a little strange, but I think it is better than the alternative, where everything is tiny.

This should be exactly the same result as if you manually check that "Override HiDpi scaling behaviour" box.

[reportmill]

Yes, it's definitely better to have that override turned on. I don't think I'll be able to do anything about the wacky text rendering - I think it's an artifact of scaling the small window backing store up by 2x. Just have to live with it until I can move to Java 9+.

[shannah]

Published new version that fixes the HiDPI issue as discussed here. It should just work if you download+reinstall your app again.

[reportmill]

Works perfect - thanks Steve!