#127 Check "JAVA_HOME" Environment Variable

[AntumDeluge]

Please forgive me if I have missed something.

It appears to me that executables generated with Launch4j search the registry for Java installations. However, some users may have a custom setup. For example, I am using a portable OpenJDK build, & I have placed its files in C:\Development\Java\java-10-openjdk. Being that I didn't use an installer, I had to manually create the registry keys to get it to recognize my Java environment:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft]

[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit]
"CurrentVersion"="1.8.0_181-1-ojdkbuild"

[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit\1.8.0]
"JavaHome"="C:\\Development\\Java\\java-1.8.0-openjdk"

[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JDK]
"CurrentVersion"="10.0.2.1-ojdkbuild"

[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JDK\10]
"JavaHome"="C:\\Development\\Java\\java-10-openjdk"

Otherwise, the only way (that I know of) to make the executable run is to fill in the path tag in the config.xml file:

<launch4jConfig>
  ...
  <jre>
    <path>C:\Development\Java\java-10-openjdk</path>
    ...
  </jre>
</launch4jconfig>

But, if I'm not mistaken, that hardcodes the Java path into the executable. So, it wouldn't necesarrily work on another machine.

Would be nice if when the L4j executable cannot find any Java registry entries, it checked for the JAVA_HOME environment variable.

[AntumDeluge]

I am using Launch4j version 3.12.

Edit: Perhaps it would be good to check the JRE_HOME & JDK_HOME variables as well.

[ADAM]

I think this and the ability to recognise installs of azul/zulu would be important.

[TomK]

Especially in the light of the JDKs distributed by https://adoptopenjdk.net/ or http://jdk.java.net/ that don't use installers any more (plain ZIP files), the registry entries are getting more and more irrelevant. JAVA_HOME should definitely be checked.

Ideally it should be possible to configure specific environment variables that should be check e.g. JAVA_HOME first, then JDK_HOME, then JRE_HOME, and then maybe even "MY_APP_JAVA_HOME"

Ideally, if everything fails, searching the PATH for a java.exe (or javaw.exe) would be a really nice fallback.

[Per]

We have the same problem. People are downloading the ZIP distribution (java 11) from Oracle and from my understanding this does not work with Launch4j??

Is there any workaround for this at all?

I suggest searching environment variable JAVA_11_HOME for java 11 as a fallback if nothing is found in the registry (and we have configured "min version = 11").

Can we point to a jdk/jre in the l4j.ini file?
add something to PATH?
Any workaround at all we can implement?

I assume adding environment variable check is easy, but this is more of a policy decision?

[Per]

AntumDeluge, I tried setting the <path> as you describe, but it does not seem to work with Oracle JDK 11 zip distribution.
Is it possible to use environment variables in the jre <path> element?</path></path>

[AntumDeluge]

I haven't tried using enviroment variables in the path tag. But I doubt that Launch4j expands variables. I will try it when I get a chance. Something like:

<path>%JAVA_HOME%</path>

[Per]

[Mc Solaar]

<path>%JAVA_HOME%</path>

works, but it would be better the "minVersion" option also checks the PATH, because the registry entries are deprecated

[Per]

Totally agree with Mc Solaar, having multiple <path> elements supported would be a great improvement.
In our case we would probably do something like this:</path>

<!-- search locally if we have bundled jdk 11 -->
<path>jdk</path>  

<!--multiple java versions installed -->
<path>%JAVA_11_HOME%</path>

 <!-- default if nothing else is found -->
<path>%JAVA_HOME%</path>

[Warren Prescott]

I can get it to work by putting %JAVA_HOME% in <jre><path>. </path></jre>

But what I really want Launch4J to do is to just use the first Java it finds on the %PATH% (that obeys min/max version etc), but I don't think it likes multiple paths in that field.

[Grzegorz Kowal]

Hi,

It would be possible to search through multiple paths. The problem is that the registry keys offered a standard way to determine the correct version. With the path approach this is not possible or has to be based on output of java -version. This could work but there is no guarantee that different vendors stick to one format. I think that for start it's better to run anything it finds in the specified paths.

Till then I also recommend the bundling of entire JRE and using a relative path. The installation package will be bigger but this solves the problem completely - you don't have to worry what java is installed you simply deliver exactly what is needed. This is the best option IMO.

Best regards,
Grzegorz

[Warren Prescott]

We have several applications, and so provide the JRE in another folder. Can <path> be pointed to a relative path to use this JRE? This would avoid bundling the JRE multiple times.</path>

[Grzegorz Kowal]

Yes, the path can be relative.

[TomK]

Due to the GPL licence of the JDK it's not always possible to bundle the JRE with an application (e.g. when the application is using a license that is not compatible with the GPL, such as Apache or BSD).

And many JDK distributions don't use the registry anymore.

I think the ability to supply multiple paths, and then Launch4j simply picks the first one with a valid JRE without validating the version would be OK.

@warren: you could use a symlink for that

[Grzegorz Kowal]

Actually it's GPL with classpath exception, so it does not have to be infectious as long you are using it as a runtime and not creating derivative work like your own JRE. It's worth studying the license carefullly or forwarding it to a legal department if you have one as it could be valuble option.

[TomK]

Well, not even the Apache's legal department is certain if they are allowed to bundle the JDK with NetBeans (as the Apache license is not compatible with the GPL). So as a private person I will not risk a lawsuit from Oracle - but this is getting off-topic now.

[Grzegorz Kowal]

It's a point. In that case try the attached head.o which implements multiple path search. Nothing changed in the configuration, so it's possible to set the bundled path to:

c:\somepath\jdk;%JAVA_HOME%;%PATH%

Semicolon is the delimiter since this will be the case in PATH anyway. Max length for the path specification is 260 chars but the expanded (from env. variables) path can be up to 32KB. Should be enough.
This does not check the version! First path that has a java.exe or javaw.exe (depending if you're using gui or console launcher) will be selected. First means from left to right as specified and as set in the expanded variables.

BR,
Grzegorz

[Warren Prescott]

I'm having an issue with the relative path processing.

I have the following directory structure:

C:\temp\
C:\temp\AdoptOpenJDK\  <and children files>
C:\temp\bin\ <which is where my .exe is>

My %PATH% is set to:

C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\dotnet\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\

My Launch4J config \<path> is set to:

%JAVAHOME%;%PATH%;..\AdoptOpenJDK\bin

However using procmon to see what is happening, it is looking under:

C:\temp\bin\Files\Microsoft SQL Sesrver\Client SDK\ODBC\170\AdoptOpenJDK\bin

It looks as if the relative path processing has incorrectly manipulated the path strings.

[Grzegorz Kowal]

The head.o should be placed in launch4j\head folder.
Inspect the output log files to see how it works (--l4j-debug , look for 'check launcher')
Also keep in mind that if the PATH contains a lot of paths then it can take more time check all of them, though I don't see much of a difference during startup.

[David Tuma]

This is a great improvement - thanks so much! It's taking things a step in the direction of letting users run an app with a version of Java 11 they already have on their computer.

One thing I notice though: with a desire to have launch4j search for a JRE in the JAVA_HOME and the PATH, I used the following:

<path>%JAVA_HOME%;%PATH%</path>

But if no JRE is found in this search path, launch4j displays the error message "This application was configured to use a bundled Java Runtime Environment but the runtime is missing or corrupted." That error message isn't accurate, so it could be confusing to end-users.

Fortunately, it looks like I can get the behavior I need if I use both a <path> and a <minVersion>

[Grzegorz Kowal]

You're right, I'll change it. In the meantime you can override the default error message using the configuration. I've noticed the 'bundled' naming in the config and code might have other meaning now but decided to leave that. Maybe I'll just correct the label in GUI and the message for now.

[Warren Prescott]

It seems to work great, I used <path>%JAVA_HOME%;%PATH%</path> and it even seems to check it JAVA_HOME\bin automatically too!

One bug I have found though, is that if JAVA_HOME or the path on the PATH directory is in quotes, then it doesn't seem to find it.

[Grzegorz Kowal]

Fixed the quotes.