Ошибка the application requires a java runtime environment

C:Usersxxx>java -version
openjdk version "1.8.0_72"
OpenJDK Runtime Environment (Zulu 8.13.0.5-win64) (build 1.8.0_72-b15)
OpenJDK 64-Bit Server VM (Zulu 8.13.0.5-win64) (build 25.72-b15, mixed mode)

KSE uses launch4j under Windows. As far as I know, launch4j searches the usual installation paths for a Java runtime. And it probably assumes the Oracle standard folder names.

What you can do as a workaround: Create a copy of the JRE folder in the KSE installation folder and rename it to «jre». That’s the path where launch4j/KSE searches first.

Would you mind re-testing this issue and, if necessary, file an upstream ticket at launch4j? OpenJDK is a relevant platform, I guess.

Is OpenJDK really relevant on Windows? There are no official builds for Windows, the Zulu builds are only 64bit and it’s quite cumbersome to compile OpenJDK on Windows.

Anyway, I’ll try to re-produce this issue and see what can be done about it.

I am currently coaching a Scrum team in the German bank industry. Because OpenJDK is used in production on Linux, all developers also use OpenJDK (Zulu) on their Windows workstations. So much for relevance. But I admit, this is just one project, I cannot speak for the rest of the software development world. Feel free to do whatever seems appropriate. Thank you for your swift response and for kindly considering our situation.

Okay, so I have checked the source code of launch4j and it searches the registry (not the file system) for entries from Oracle and IBM:
«SOFTWAREJavaSoftJava Runtime Environment»
«SOFTWAREJavaSoftJava Development Kit»
«SOFTWAREIBMJava2 Runtime Environment»
«SOFTWAREIBMJava Development Kit»

However, the Zulu installer creates the following registry entry:
«SOFTWAREAzul SystemsZulu»

There is already a feature request to add support for Zulu OpenJDK to launch4j:
https://sourceforge.net/p/launch4j/feature-requests/103/

It might help to comment on the feature request, so the author of launch4j notices that there is not only one user that wants this feature.

Also, as I have already mentioned, there is always the option to copy the jre folder into the KSE folder. KSE then uses this local runtime preferredly.

I know this is an old issue but since it is still relevant here is my solution:

Create a registry file with the following content and import it into your regsitry

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREJavaSoft]

[HKEY_LOCAL_MACHINESOFTWAREJavaSoftJava Development Kit]
"CurrentVersion"="1.8"

[HKEY_LOCAL_MACHINESOFTWAREJavaSoftJava Development Kit1.8]
"JavaHome"="C:\Program Files\Zulu\zulu-8"
"MicroVersion"="0"

Obviously change the JavaHome to your Zulu installation. So far this works quite well for me.

Hi,
@chhe your version did not work for me, im running windows 10 Pro 64bit and i needed to change your workaround like so:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeJavaSoft]

[HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeJavaSoftJava Runtime Environment]
"CurrentVersion"="11.0"

[HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeJavaSoftJava Runtime Environment11.0]
"JavaHome"="C:\Users\thomas\scoop\apps\adoptopenjdk-openj9\current"
"MicroVersion"="0"```

this works for me.

On Windows, one possible solution is to create a directory link inside the KSE installation directory using the cmd.exe built-in mklink command (available in Vista/Server 2008 or newer); e.g.:

cmd /c mklink /d "C:Program Files (x86)KeyStore ExplorerJRE" "C:Program FilesAdoptOpenJDKJRE"

(change paths as appropriate, of course)

Is OpenJDK really relevant on Windows?

Now that Oracle is forcing corporate JRE users to a subscription model, yes it is.

I’ve tested the AdoptOpenJDK JRE 8 distribution and it seems that KSE works with it without any problems. (Launch4j doesn’t support it yet, but that’s a separate problem.)

The MSI installer of AdoptOpenJDK’s Java 8 distribution has an option to add registry entries that are compatible with Oracle’s JDK (under HKEY_LOCAL_MACHINESOFTWAREJavaSoftJava Development Kit):

If this option is selected launch4j (kse.exe) finds the AdoptOpenJDK installation and starts KSE just fine.

This is a new feature they have added to the AdoptOpenJDK MSI installer that didn’t exist when I posted earlier. This is good to know — thanks.

I tried Bill Stewart’s solution And it works OK with my OpenJDK 11 installation. I think it might be implemented in KeyStore Explorer’s setup. Something like «where is yout Java installation?».

Caveat: The 32-bit Launch4j will not detect the Oracle registry entries added by the 64-bit AdoptOpenJDK installer (you would have to install the 32-bit version of the JDK/JRE). But again: This is not KSE’s problem at all, but rather an issue with Launch4j. I have worked around this by creating a «launcher» script that uses the JAVA_HOME environment variable and launching javaw -jar kse.jar.

Caveat: The 32-bit Launch4j will not detect the Oracle registry entries added by the 64-bit AdoptOpenJDK installer (you would have to install the 32-bit version of the JDK/JRE).

That’s not true. Launch4j has a configuration option called «runtimeBits», which determines which registry paths are checked for JRE locations:

runtimeBits
Optional, defaults to 64/32; Allows to select between 64-bit and 32-bit runtimes.

For KSE it’s the default, which means both 64 bit and 32 bit Java runtimes are found.

I tried Bill Stewart’s solution And it works OK with my OpenJDK 11 installation. I think it might be implemented in KeyStore Explorer’s setup. Something like «where is yout Java installation?».

Then KSE won’t start anymore when the JRE location changes. The right place for detecting the JRE is the launcher. There has already been a patch provided for launch4j which solves this problem, but we’ll have to wait for the next release of launch4j.

That’s not true. Launch4j has a configuration option called «runtimeBits», which determines which registry paths are checked for JRE locations…For KSE it’s the default, which means both 64 bit and 32 bit Java runtimes are found.

Oddly, on one system, the registry values weren’t there even though the feature was selected in the installer. Repairing the AdoptOpenJDK JRE installation fixed the problem and indeed kse.exe works as needed even though only the 64-bit values are added. This is good. Thanks for the follow-up.

Now, of course, it’s requiring 1.8 in a day where OpenJDK 15 is released. Why don’t you set a minimum version with no maximum, instead of a specific version?

This is a problem. Becouse I have both 1.8 and 15 installed.

And if I click on JAR file it opens and works correctly with 15 AdoptOpenJDK

@lawrence-dol Java 1.8 is the minimum version. KSE works perfectly fine with Java 15. You just have to check the option to create the registry entry when installing AdoptOpenJDK as described on the download page.

@Mart-Bogdan Did you follow the instructions on the download page of KSE or a few comments above in this ticket (#52 (comment))?

As the launch4j project seems to be pretty dead (no release for more than two years), I have replaced launch4j with my own Windows launcher that uses the JAVA_HOME environment variable.

If you want to try the new launcher, you can download a beta version here:
kse.zip

Just replace kse.exe in your KSE installation with the file from the ZIP file.

The next release of KSE will include this new launcher.

@kaikramer

@lawrence-dol Java 1.8 is the minimum version. KSE works perfectly fine with Java 15. You just have to check the option to create the registry entry when installing AdoptOpenJDK as described on the download page.

Fair enough, though I already knew that from running it with JDK 15 using the -jar command line form. In my defense, I was believing the loader, which states, «This application requires a Java Runtime Environment 1.8.0», not «This application requires Java Runtime Environment 1.8.0 or later». The former is exact, the latter is a minimum.

For a while I was mistakenly under the impression that the loader was needed instead of being a mere convenience, and that the software require exactly that version. It would probably help the situation to include a basic command line in the «Running» section, along with a statement along the lines of «KSE can be run by simply launching the JAR or by using the Windows executable. blah blah blah».

Regardless, thanks for the program — it’s excellent and the loader issue is, in the end, a minor irritation at worst. I do appreciate your efforts and did not mean to sound ungrateful.

My recommendation on this front is that the launcher should perform several searches for increased robustness.

1. Search HKLMSOFTWAREJavaSoft subkeys for highest version number and use JavaHome value.

2. Use value of JAVA_HOME environment variable.

3. Use value of JRE_HOME environment variable.

4. Search the path for javaw.exe and use parent of parent subdirectory name.

In addition, the installer could create a JRE symlink in the application directory to the correct path.

FWIW I built an Inno Setup (IS) installer for KSE that adds the above features. The IS installer compiles to a bit larger size than NSIS but it looks and acts better (IMO) and can be localized fairly easily. (Let me know if you’re interested.)

In thinking about this a bit more, I wrote a launcher executable that uses a kse.ini file (same directory as .exe file) that looks like this:

[JavaHome]
Path=C:Program FilesAdoptOpenJDKJRE11

The launcher uses this path to launch a command line such as:

"java home pathbinjavaw.exe" -jar "kse install pathkse.jar" […]

The installer has a Select Java Runtime page where you specify the Java home directory (it does some auto-detect using JavaSoft registry values, JAVA_HOME and JRE_HOME environment variables, and it also searches the path). If you run a reinstall, it will rewrite the kse.ini file.

For anyone that wants to use KSE on Windows without the installer, you could provide a sample kse.ini file and a readme.txt that says you need to manually add the Java directory to it.

This would seem to be a simple and clean solution that provides a simple way to run KSE on Windows without needing symlinks, complicated searching in the executable, etc.

Thoughts?

That would be more than adequate, though I’m surprised you didn’t do the JVM location in the launcher rather than the installer, if the ini file is not present. Perhaps because the installer is Windows specific, but the launcher code is not?

But that said, anyone using the zip package likely has more than enough skill to be able to set the path manually.

I suppose this is one approach. My thought was that the work of finding the Java runtime feels more appropriate for install time rather than run time, and it’s not hard to reinstall (or just manually edit the kse.ini file).

@Bill-Stewart I really appreciate your efforts to improve KSE and at a later point in time I will certainly take a look at your Inno Setup installer.

However, a few comments above I have posted a pre-release version of the new KSE launcher. This is going to be the solution for the launcher issue for the next KSE release. It is not complete yet, but the next KSE release is still pretty far away.

As I have said earlier, the installer is not the right place to search for JREs. Updating or switching Java runtimes after the installation is obviously not handled. And I certainly don’t want to reinstall all my Java applications just because I have switched to another JRE. So the code for locating the JRE should be in the launcher, not in the installer.

In addition to the new launcher there will be a second version of KSE for Windows coming with the next release that includes a custom Java runtime. Providing a self-contained version of KSE is probably the best solution and it might also help with some tickets describing issues that I just cannot reproduce.

Providing a self-contained version of KSE is probably the best solution…

Hmmm. I’m not so sure. When it comes to cryptography, I want it to use the version I have installed. I think I’d be concerned if my keystore manager is using crypto from JSE 15, released, say in 2018, and it was 2025 and JSE 22 is the latest. Seems like bundling a JVM is just adding maintenance overhead.

Still, your project, your call.

And I certainly don’t want to reinstall all my Java applications just because I have switched to another JRE. So the code for locating the JRE should be in the launcher, not in the installer.

This is a persuasive argument in favor of including this logic in the launcher rather than the installer; I agree with this assessment.

After thinking about this some more, it seems this problem would be nicely solved on Windows by using a DLL that can detect a Java installation using the aforementioned techniques and return information about it. I wrote a prototype that exports 4 functions:

• IsJavaInstalled() — returns non-zero if Java is detected, or 0 if not detected

• IsJava64Bit() — returns non-zero if the detected Java is 64-bit, or zero if not 64-bit

• GetJavaHome() — returns a unicode string in an output parameter containing the Java home directory location

• GetJavaVersion() — returns a unicode string in an output parameter containing the version number embedded in java.exe

I am doing some more testing, but it seems to me that this functionality would be useful not just to the KSE project but for anyone writing Java programs to be run on Windows.

@Bill-Stewart Sounds like a good idea. What language did you use?

It’s written in Object Pascal (FPC) and I have both x86 and x64 DLL binaries. The x86 version can detect 64-bit Java installations because it knows how to read the 64-bit registry and file system when running on a 64-bit OS.

Updated to v0.3. Replaced IsJava64Bit() function with a more generic IsBinary64Bit() function. (Useful in case Java detection fails but you know the path and filename of java.exe and want to know if it’s 32-bit or 64-bit.)

@Bill-Stewart I took a quick look at your JavaInfo project and like how well documented and easy to understand everything is. 👍

Not sure if this is a problem or not, but right now any Java installation that has a registry entry under «HKLMSOFTWAREJavaSoft» wins, no matter how old this Java version is.

For example, someone has an old Oracle Java 8 installation and then installs Azure Zulu 15, which creates a registry entry, but under «HKLMSOFTWAREAzul SystemsZulu» and adds its «bin» directory to the system path. JavaInfo will then still only find Java 8, which is not what the user would expect.

Something similar happens when AdoptOpenJDK 11 or 15 is installed and the option to set JAVA_HOME is checked (but not the JavaSoft option). Most users would expect that JAVA_HOME takes precedence over anything else.

One could argue that the user simply has to uninstall old Java JREs/JDKs, but an existing workaround is obviously not enough, otherwise this ticket would not have 34 comments.

@kaikramer Excellent feedback! It seems that JAVA_HOME/JRE_HOME/JDK_HOME should take precedence over the registry. This is sensible and I think you are right about that.

It seems we also need to add SOFTWAREAzul Systems to the registry search (I wasn’t aware of that JDK/JRE). Are there any other JDK/JRE I can add to the registry searching?

(Aside: Thanks to feedback from the Inno Setup developer, I am also going to change the license to LPGL so that others can use the DLL more freely.)

Thanks again for the feedback!

@Bill-Stewart launch4j searches the following registry locations:

«SOFTWAREJavaSoftJava Runtime Environment»,
«SOFTWAREJavaSoftJava Development Kit»,

«SOFTWAREJavaSoftJRE»,
«SOFTWAREJavaSoftJDK»,

«SOFTWAREAzul SystemsZulu»,
«SOFTWAREAzul SystemsZulu»,

«SOFTWAREIBMJava Runtime Environment»,
«SOFTWAREIBMJava Development Kit»,

Amazon Corretto by default creates a registry entry under «SOFTWAREJavaSoftJDK» and updates both JAVA_HOME and PATH, so nothing special to do here:

@kaikramer Outstanding, thanks! I agree that the environment variable (JAVA_HOME, etc.) should take precedence over the registry data.

@kaikramer I have published v0.4 using LPGL license and the suggested changes. Thanks for the feedback! Of course let me know if you have any other suggestions.

JavaInfo.dll has been updated to v1.0.0. I noticed that AdoptOpenJDK also adds registry data so I added that to the list of registry locations it searches. Per previous suggestions the search order is the following:

1. JAVA_HOME/JDK_HOME/JRE_HOME environment variables (in that order)
2. Directories in Path
3. HKEY_LOCAL_MACHINESOFTWAREJavaSoft in registry
4. HKEY_LOCAL_MACHINESOFTWAREIBM in registry
5. HKEY_LOCAL_MACHINESOFTWAREAdoptOpenJDK in registry
6. HKEY_LOCAL_MACHINESOFTWAREAzul SystemsZulu in registry

Thanks for the feedback!

@Bill-Stewart It makes sense that the environment variables have precedence over the registry entries, because the user can check/change them pretty easily. But IMHO all registry locations should be searched equally for the newest Java version.

3. `HKEY_LOCAL_MACHINESOFTWAREJavaSoft` in registry
4. `HKEY_LOCAL_MACHINESOFTWAREIBM` in registry
5. `HKEY_LOCAL_MACHINESOFTWAREAdoptOpenJDK` in registry
6. `HKEY_LOCAL_MACHINESOFTWAREAzul SystemsZulu` in registry

I would do these registry entries in 5,6,3,4 order. The JavaSoft and IBM entries are likely to be detritus from old installations, whereas AdoptOpenJDK and Azul, if they exist, are much more likely to be the current install.

Otherwise, I completely agree with this search order.

@lawrence-dol Thanks for the feedback! I am updating the DLL such that it returns the latest version across all registry subkey searches (as @kaikramer suggested — and I agree) so the specific order shouldn’t matter. We definitely need to search the JavaSoft subkey because it gets used by:

• AdoptOpenJDK if JavaSoft (Oracle) registry keys component selected at install (it is not selected by default)
• Amazon Corretto if Setup Registry Keys component selected at install (it is selected by default)
• Azul Zulu
• Oracle Java

Also FYI: From my testing the Azul SystemsZulu subkey should actually not ever get searched if the Zulu install completes successfully because Zulu adds itself to JavaSoft as noted above. (I added mainly for completeness.)

Released version 1.1.0 of the DLL. The search order is the following:

1. if JAVA_HOME/JDK_HOME/JRE_HOME environment variables (in that order) are defined, use as Java home directory.

2. If environment variables above are not defined, search the directories named in the Path for java.exe.

3. If the environment variables are not defined and java.exe is not in the path, then search the following registry subkeys for Java installations:

   HKEY_LOCAL_MACHINESOFTWAREAdoptOpenJDK
HKEY_LOCAL_MACHINESOFTWAREAzul SystemsZulu
HKEY_LOCAL_MACHINESOFTWAREIBM
HKEY_LOCAL_MACHINESOFTWAREJavaSoft

   The registry search uses whichever of the above subkeys contains the Java home directory for the latest version of Java.

The Java version returned by the GetJavaVersion() DLL function is the file version of javahomebinjava.exe (where javahome is the Java home directory).

Thanks for all the feedback!

As the launch4j project seems to be pretty dead (no release for more than two years), I have replaced launch4j with my own Windows launcher that uses the JAVA_HOME environment variable.
…
The next release of KSE will include this new launcher.

This comment about the new launcher is from November 2020. The most current release is 5.4.4, built on Oct 4, 2020.

So with the most current release I just ran into this problem (requires JRE 1.8). I replaced the original kse.exe with the one from the ZIP and it works like a charm.

Would it be a big deal to build a version 5.4.5 with the new launcher?

Why I run into the problem:
I use Scoop to install almost everything I need on an almost «blank» windows machine without admin permissions. Therefore I don’t have any registry entries about Java and I never see or use the KSE installer. KSE and Java(s) are just dropped on the disk and JAVA_HOME/PATH vars are set.

It looks like @kaikramer has updated the Windows launcher executable to use JavaInfo.dll for the next version. JavaInfo.dll uses a variety of techniques to detect Java on Windows.

@sburkard The new launcher is not ready for a public release yet. Also, the next feature release of KSE (v5.5.0) is not that far away anymore.

I think the value of a kse.ini, as Bill suggested, is being overlooked here. If this file exists, kse.exe should treat it as the first stop in the Java runtime hunt, with a fallback to other techniques listed in the thread. I don’t like the idea of a bundled, self-contained, custom Java runtime.

Please note that AdoptOpenJDK is moving to adoptium.net and new MSI installers use the Eclipse Foundation registry subkey (rather than AdoptOpenJDK) — JavaInfo.dll has been updated to 1.3.0 to accommodate this change. Please test with latest Windows kse.exe launcher.

Closing tickets in preparation for release of KSE 5.5.0