Problem: More Flexable Java version check on Windows.

[soloopooo]

My computer ( Windows 11 Pro ) has a lot of java version:

Openjdk 16.0.2, IBM Semeru Runtime Open Edition 16.0.2.0 (In PATH, Uses as Default) IBM Semeru Runtime Open Edition 1.8.0 Openjdk 17.0.1 ...

When I directly open the exe file, It shows this window:

Then the application opens the Oracle java download page.

But when I use command prompt:

It can be run normally.

And, Your readme said that this application supports running on Java above 1.8 .

So how about making checking java version more flexable ?

Edit: This problem happens from V8.2 to now.

Edit 2: My computer doesn't have ORACLE Version Java 1.8.

Edit 3: I just checked version 3.0 and version 7.0. They all went into this issue.

[RoanH]

Interesting, this appears to be an issue with the software I use to create Windows executables. It seems like it either fails to find one of the installed runtimes or fails to read its version properly. Whether this is caused by an IBM runtime or Windows 11, I don't know. I know that Openjdk should work as that is what I personally run as well (under Windows 10 at least).

The way you're running the executable from the command line in your screenshot is effectively treating the exe as a runnable jar. Which means the entire Java check is bypassed, so it's probably easier to just use the runnable jar distribution instead of the exe. The jar is compiled for Java 1.8+ which I just verified to be properly reflected in the output class files. There's no strict requirement on needing the Oracle runtime.

I also checked my build process, but nothing changed from v8.1 to v8.2 so I don't see an obvious reason there either. I'll try updating as many of my builds tools as possible in case support was already added and I do have plans for an installer that would completely drop the requirement on having a runtime installed at all. But I'm not sure how effective the first will be and I have no time estimate for the latter.

[soloopooo]

I also checked my build process, but nothing changed from v8.1 to v8.2

Because I started using this program from v8.2, I can just provide problems newer than version 8.2. Sorry for that, I don't know whether it shows before v8.2.

[RoanH]

I also checked my build process, but nothing changed from v8.1 to v8.2

Because I started using this program from v8.2, I can just provide problems newer than version 8.2. Sorry for that, I don't know whether it shows before v8.2.

Alright, then I think it's probably safe to assume this has always been an issue for any version.

[soloopooo]

ADD: I just checked version 3.0 and version 7.0. They all went into this issue.

[RoanH]

ADD: I just checked version 3.0 and version 7.0. They all went into this issue.

Alright, thanks for testing.

[soloopooo]

I build myself an exe file.

I use exe4j to build it, and it shows correctly ( I didn't hide the console window in the first pic ).

Maybe you can search JAVA_HOME variables or something first? Because exe4j can specify the scan folders of jre, and by default:

[RoanH]

Interesting, I thought launch4j (what I use for executables) did search JAVA_HOME. But I can't seem to get a clear answer to that. I've also since updated all my build systems to the latest version. I've made a few test versions with some environment variables set to be searched. I would appreciate it if you could test these.

1. Normal executable with only the build system updated, most likely this one still does not work: https://share.roanh.dev/KeysPerSecond-v8.4-update-build.exe
2. Version where JAVA_HOME should be searched: https://share.roanh.dev/KeysPerSecond-v8.4-java-home.exe
3. Version where in addition to JAVA_HOME I also added the regular PATH variable: https://share.roanh.dev/KeysPerSecond-v8.4-home-and-path.exe

Ideally I think that the 2nd option would be best. If I can finalise everything in time the next release will also have some downloads that do not require a preinstalled JRE.

[soloopooo]

Alright, i would test then.

Edit: I tested these 3 builds, see the following:

1.

It automatically asks for the Admin permission. I don't know why.

2.

Seems good.

3.

Seems good.

[soloopooo]

Wait. Let me check which java these 2 uses.

Hmm...

Looks like they all just use the version listed in JAVA_HOME. Alright.

[Please don't ask for why java 15, because i replaced java 15 files with 16 in that folder.]

[RoanH]

Interesting, so option 1 didn't work as expected, though I'm not sure why Windows decided to make it require admin rights... it even asks for them on the system I built the exe on.

Since both option 2 and 3 works I think I'll just stick to searching JAVA_HOME for now. Option 3 probably used JAVA_HOME instead of what was in PATH because JAVA_HOME was first in the search order.

Anyway, thanks for testing! I'll update the build configuration to search JAVA_HOME starting with the next release.