#197 openJDK 11 not detected

[lin83]

Hi Grzegors,

first of all, many thanks for your hard work on this tool.

As you know, Oracle has changed their license policy and moe and more of my clients are using OpenJDK.
As openJDK comes with a zip file, without installed, it does not generate any registry keys.

We have set the JAVA_HOME variable and even when calling java-version from the command line we can see, openJDK and version 11.0.1.

But if I use the application converted as exe., I get the following error:
This application requires a Java Runtime Environment 11.0.1.

Does not matter if I select JRE, JDK or private jdk as launch4j setting.

Is there any additional setting to detect the java version based on the Java_Home variable?

Any way you could help analyzing it?
I am using launch4j 3.12

[Grzegorz Kowal]

Hi,

JAVA_HOME is not used by launch4j. It either searches the registry or you
need to specify the java directory as absolute or relative path (bundled
JRE path).
Can you attach the log created by the executable with --l4j-debug option?
The path is probably wrong.
Your best option is to bundle the JRE with the application, it'll make it
larger but you don't have to worry about what java version is installed on
the target machine. There is the option to reduce the size of such JRE
based on used modules.

BR,
Grzegorz

On Wed, Jan 2, 2019 at 4:23 PM lin83 lin83@users.sourceforge.net wrote:

---

• [bugs:#197] https://sourceforge.net/p/launch4j/bugs/197/ openJDK 11
  not detected*

Status: open
Group: 3.x
Created: Wed Jan 02, 2019 03:23 PM UTC by lin83
Last Updated: Wed Jan 02, 2019 03:23 PM UTC
Owner: nobody
Attachments:

• java_version.png
  https://sourceforge.net/p/launch4j/bugs/197/attachment/java_version.png
  (6.2 kB; image/png)

Hi Grzegors,

first of all, many thanks for your hard work on this tool.

As you know, Oracle has changed their license policy and moe and more of
my clients are using OpenJDK.
As openJDK comes with a zip file, without installed, it does not generate
any registry keys.

We have set the JAVA_HOME variable and even when calling java-version from
the command line we can see, openJDK and version 11.0.1.

But if I use the application converted as exe., I get the following error:
This application requires a Java Runtime Environment 11.0.1.

Does not matter if I select JRE, JDK or private jdk as launch4j setting.

Is there any additional setting to detect the java version based on the
Java_Home variable?

Any way you could help analyzing it?
I am using launch4j 3.12

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/launch4j/bugs/197/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[lin83]

Hi Grzegorz,

that's th output of the debug:

Version: 3.12
CmdLine: F:\Testing\test-0.0.1-SNAPSHOT-jar-with-dependencies.exe --l4j-debug
WOW64: yes
Working dir: F:\Testing\LPU.
Java min ver: 1.011.000_001
Java max ver:
64-bit search: SOFTWARE\JavaSoft\Java Development Kit...
32-bit search: SOFTWARE\JavaSoft\Java Development Kit...
64-bit search: SOFTWARE\JavaSoft\JDK...
32-bit search: SOFTWARE\JavaSoft\JDK...
64-bit search: SOFTWARE\IBM\Java Development Kit...
32-bit search: SOFTWARE\IBM\Java Development Kit...
64-bit search: SOFTWARE\IBM\Java Development Kit...
32-bit search: SOFTWARE\IBM\Java Development Kit...
Error msg: This application requires a Java Runtime Environment 11.0.1
Open URL: http://java.com/download

But let me ask additional questions please:
OpenJDK does not provide any installer, therefore it does not creates registry entries.
How will launch4j work with it without the registry entries?

Bundling Java is one option, but it requires to maintain Java in the application as well.
Specifying the path also does not work as I have openJDK on C: my colleague on D:.

Is there a reason not to use JAVA_HOME (maybe as fallback)?

Java_Home is set normally as it is used for many other purposes as well.
Or would it be possible to "fallback" and to allow wildcards as Java version, so any version could be allowed (if that would then still work for launch4j...)

[Craig Cavanaugh]

I see that bundling a JVM negates some of the benefits of launch4j when it comes to cross platform builds for an application when using Maven, Gradle, etc..

I too see the benefit of JAVA_HOME as a viable fallback to not finding registry entries.

[lin83]

Hi Grzegorz,
I was sitting a little longer on it now and finally got it running!

The confusion was the JRE bundle (as name).
I did not wanted to bundle my jre, but you can use %JAVA_HOME% and leave min and max empty.
Works like a charm and is exactly doing what I asked for!

So definitly my prefered solution and you did a great job ...

@Craig
As suggested:
Use %JAVA_HOME% as jre bundle and leave min and max empty.
Works... and tbh version check is not required by me :-)

[TomK]

There is an open ticket for allowing to check the JRE through environment variables in addition to a bundled JRE:

https://sourceforge.net/p/launch4j/feature-requests/127/

[Grzegorz Kowal]

Hi,

Great that you've got it working, nice idea.

BR,
Grzegorz

On Tue, Jan 8, 2019, 16:03 thomas kellerer <tkellerer@users.sourceforge.net
wrote:

There is an open ticket for allowing too check the JRE through environment
variables in addition to a bundled JRE:

https://sourceforge.net/p/launch4j/feature-requests/127/

• [bugs:#197] https://sourceforge.net/p/launch4j/bugs/197/ openJDK 11
  not detected*

Status: open
Group: 3.x
Created: Wed Jan 02, 2019 03:23 PM UTC by lin83
Last Updated: Tue Jan 08, 2019 01:56 PM UTC
Owner: nobody
Attachments:

• java_version.png
  https://sourceforge.net/p/launch4j/bugs/197/attachment/java_version.png
  (6.2 kB; image/png)

Hi Grzegors,

first of all, many thanks for your hard work on this tool.

As you know, Oracle has changed their license policy and moe and more of
my clients are using OpenJDK.
As openJDK comes with a zip file, without installed, it does not generate
any registry keys.

We have set the JAVA_HOME variable and even when calling java-version from
the command line we can see, openJDK and version 11.0.1.

But if I use the application converted as exe., I get the following error:
This application requires a Java Runtime Environment 11.0.1.

Does not matter if I select JRE, JDK or private jdk as launch4j setting.

Is there any additional setting to detect the java version based on the
Java_Home variable?

Any way you could help analyzing it?
I am using launch4j 3.12

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/launch4j/bugs/197/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Luke Usherwood]

Since shrinking & bundling the JRE got a few mentions, I think it's worth mentioning that some of the various OpenJDK distributions that have "popped up" supply combinations of both JRE vs JDK as well as Zip vs Installers. We found the JRE from AdoptOpenJDK was even smaller than we were able to achieve from the JDK using the provided jlink tools (which we found to be an involved and error prone process) so just grabbing the JREs from there was a very convienent solution.

[Robert Brown]

OpenJDK/JRE comes with installers. Also add windows registry information including program location information. As most people will be using OpenJDK/JRE, supporting OpenJDK will be essential.

My one more vote for this feature.
Thanks in advance.

[Grzegorz Kowal]

If you mean the Adopt installer, this will work. Just select the registry key option during installation.

Best regards,
Grzegorz

[Uwe Mock]

Grzegorz,

I did not get it running with the Adopt installer. I cannot find a "registry key option" during installation. I tried the OpenJDK 12 installer.

With the ojdkbuild installer, everything works fine.

However, the Adopt website seems more user-friendly to me. I would like to have both options working. Any chance?

[Luke Usherwood]

I cannot find a "registry key option" during installation.

Educated guess: I think you might need to take care to get the "Install JRE" option (So not "Download" and not "JDK").

Adopt have (thankfully) stopped bundling a second JRE installer within the JDK installer, like Sun/Oracle used to always do. The JRE is the one you will want to deploy for your users, as it's the smallest.

[Uwe Mock]

I have downloaded the JRE (not JDK) installer as an MSI file.

[Luke Usherwood]

In the 3rd step of the "JRE With Hotspot" wizard, look for 2 additional
options in the tree, disabled by default:

? * set JRE_HOME
? * JavaSoft (Oracle) registry keys

(I was using the Windows x64 installer.)

Cheers,
Luke

On 17/09/2019 18:40, Uwe Mock wrote:

I have downloaded the JRE (not JDK) installer as an MSI file.

---

[bugs:#197] https://sourceforge.net/p/launch4j/bugs/197/ openJDK 11
not detected

Status: open
Group: 3.x
Created: Wed Jan 02, 2019 03:23 PM UTC by lin83
Last Updated: Tue Sep 17, 2019 04:13 PM UTC
Owner: nobody
Attachments:

• java_version.png
  https://sourceforge.net/p/launch4j/bugs/197/attachment/java_version.png
  (6.2 kB; image/png)

Hi Grzegors,

first of all, many thanks for your hard work on this tool.

As you know, Oracle has changed their license policy and moe and more
of my clients are using OpenJDK.
As openJDK comes with a zip file, without installed, it does not
generate any registry keys.

We have set the JAVA_HOME variable and even when calling java-version
from the command line we can see, openJDK and version 11.0.1.

But if I use the application converted as exe., I get the following error:
This application requires a Java Runtime Environment 11.0.1.

Does not matter if I select JRE, JDK or private jdk as launch4j setting.

Is there any additional setting to detect the java version based on
the Java_Home variable?

Any way you could help analyzing it?
I am using launch4j 3.12

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/launch4j/bugs/197/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Luke Usherwood]

In the 3rd step of the "JRE With Hotspot" Wizard (Windows x64, downloaded from AdoptOpenJDK), look for 2 additional options in the tree, disabled by default:

• set JRE_HOME
• JavaSoft (Oracle) registry keys

[Uwe Mock]

Gosh, it's inside the components tree. I expected checkboxes as this is something else as "copy these files as well"... Thanks for pointing this out.

[Grzegorz Kowal]

I am closing this one as FR #127 allows to use it with environment variables and latest AdoptOpenJDK is able to register itself.

[Garret Wilson]

Can someone confirm the latest behavior regarding detection of JAVA_HOME? I'm using Launch4J 3.14 in combination with the launch4j-maven-plugin to produce foobar.exe. The distributable will not have a JDK included. The users are expected to download a JRE, normally Adoptium. We cannot assume that the user has found some installation checkbox to use JavaSoft/Oracle registry keys. We can provide instructions for the user to verify or set JAVA_HOME, as this is the most cross-platform, de-facto standard for detecting Java.

Will Launch4J 3.14 detect Adoptium Java 17 based solely on the presence of the JAVA_HOME environment variable, or will it not? If it will not, I'm going to ditch Launch4J altogether (see JAVA-240), as it would be useless if it doesn't work with Adoptium without some special throwback registry detection.

Follow-up-question: If a user has installed Oracle Java 8 using the installer (thus setting the registry to point to Oracle Java 8), and then installed Adoptium Java 17 by unpacking the distributable and setting the JAVA_HOME environment variable to point to Adoptium 17, will Install4J be able to detect JAVA_HOME and use Adoptium 17? Or will it get hung up on the fact that there is a registry setting for Oracle Java 8, and fail because Java 8 doesn't meet the minimum criteria in my configuration requesting at least Java 17?

[Grzegorz Kowal]

You can configure Launch4j to use the JAVA_HOME variable, but like most
other applications using this approach it only detects that that Java is
actually available but not its version. So you can end up starting a
different version than needed.

Regarding the registry search you will not get hung up on old version if
you configure the search correctly. If the minimum version is 17 there is
no way 8 is going to be used based on the registry search.

You could configure launch4j to use min 17 and bundledJreAsFallback with
JAVA_HOME, but if 8 is only installed and JAVA_HOME is pointing to it, then
this version will be used.

Your best option is to bundle the required runtime. You don't force the
users to install a system wide dependency, imagine you'd like to update to
a higher version of Java. How do you do that? With the bundling of runtime
the user doesn't care what version you are using or if you even switch to a
completely different platform. Would the increase in setup size really
matter today given the average bandwith?

I think you should reconsider if bundling is not a better option, though I
am not up to date with the licensing terms in case of Adoptium/Temurin and
bundling. You'd have to check if it fits your needs.

Best regards,
Grzegorz

On Fri, Aug 5, 2022, 16:57 Garret Wilson garretwilson@users.sourceforge.net
wrote:

Can someone confirm the latest behavior regarding detection of JAVA_HOME?
I'm using Launch4J 3.14 in combination with the launch4j-maven-plugin
https://github.com/lukaszlenart/launch4j-maven-plugin to produce
foobar.exe. The distributable will not have a JDK included. The users
are expected to download a JRE, normally Adoptium https://adoptium.net/.
We cannot assume that the user has found some installation checkbox to use
JavaSoft/Oracle registry keys. We can provide instructions for the user to
verify or set JAVA_HOME, as this is the most cross-platform, de-facto
standard for detecting Java.

Will Launch4J 3.14 detect Adoptium Java 17 based solely on the presence of
the JAVA_HOME environment variable, or will it not? If it will not, I'm
going to ditch Launch4J altogether (see JAVA-240
https://globalmentor.atlassian.net/browse/JAVA-240), as it would be
useless if it doesn't work with Adoptium without some special throwback
registry detection.

Follow-up-question: If a user has installed Oracle Java 8 using the
installer (thus setting the registry to point to Oracle Java 8), and then
installed Adoptium Java 17 by unpacking the distributable and setting the
JAVA_HOME environment variable to point to Adoptium 17, will Install4J be
able to detect JAVA_HOME and use Adoptium 17? Or will it get hung up on
the fact that there is a registry setting for Oracle Java 8, and fail
because Java 8 doesn't meet the minimum criteria in my configuration
requesting at least Java 17?

---

• [bugs:#197] https://sourceforge.net/p/launch4j/bugs/197/ openJDK 11
  not detected*

Status: closed-fixed
Group: 3.x
Created: Wed Jan 02, 2019 03:23 PM UTC by lin83
Last Updated: Tue Jan 26, 2021 07:45 PM UTC
Owner: Grzegorz Kowal
Attachments:

• java_version.png
  https://sourceforge.net/p/launch4j/bugs/197/attachment/java_version.png
  (6.2 kB; image/png)

Hi Grzegors,

first of all, many thanks for your hard work on this tool.

As you know, Oracle has changed their license policy and moe and more of
my clients are using OpenJDK.
As openJDK comes with a zip file, without installed, it does not generate
any registry keys.

We have set the JAVA_HOME variable and even when calling java-version from
the command line we can see, openJDK and version 11.0.1.

But if I use the application converted as exe., I get the following error:
This application requires a Java Runtime Environment 11.0.1.

Does not matter if I select JRE, JDK or private jdk as launch4j setting.

Is there any additional setting to detect the java version based on the
Java_Home variable?

Any way you could help analyzing it?
I am using launch4j 3.12

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/launch4j/bugs/197/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Garret Wilson]

Regarding the registry search you will not get hung up on old version if
you configure the search correctly. If the minimum version is 17 there is
no way 8 is going to be used based on the registry search.

No, that doesn't seem to be correct. In my Maven parent POM I have this setting for launch4j-maven-plugin:

<jre>
  <minVersion>${maven.compiler.release}</minVersion>
</jre>

Which means that in the effective POM for my project, it gets interpolated to:

<jre>
  <minVersion>17</minVersion>
</jre>

I also have JAVA_HOME pointing to OpenJDK 17. But when I run the resulting foobar.exe file, it pops up a page to java.com/download. So that's completely broken. (Sheesh, even if it couldn't find Java, then it should at least print an error message, instead of opening the browser to some ancient site to force users into the Oracle JDK.)

Update: it appears it did print the following message in the terminal in addition to popping up the browser: "This application requires a Java Runtime Environment 17". So it looks like it didn't run the JRE at JAVA_HOME, and just assumed that version (if it even looked at JAVA_HOME wouldn't work.

I think you should reconsider if bundling is not a better option ...

From what I understand (correct me if I'm wrong), "bundling" doesn't mean including the JDK in the .exe itself, but instead installing some JRE file in the same directory as the .exe file. That helps me zero --- if I'm forced to have two files, I might as well simply drop a foobar.bat file in the same directory as the uber foobar-exe.jar file; then there is no need for Launch4J at all and Java works fine as long as it's on the path. The whole point of having an .exe is that I want it to run by itself.

So everything seems broken and I can't run Launch4J with Java 17 with Adoptium using JAVA_HOME. In other words, Launch4J can't run with the most modern, best-practices configuration. So it's useless to me.

[Garret Wilson]

You can configure Launch4j to use the JAVA_HOME variable ...

So how do I do that?

So you can end up starting a
different version than needed.

That's expected. That's how relying on JAVA_HOME works. I tell the system which Java I want via JAVA_HOME, and if that version doesn't work with the JAR, Java complains. Fine.

So how do I tell Launch4J to use JAVA_HOME, ignore the registry, and stop popping up my browser to some Oracle site?

[Grzegorz Kowal]

<?xml version="1.0" encoding="UTF-8"?>
<launch4jConfig>
  <dontWrapJar>true</dontWrapJar>
  <headerType>gui</headerType>
  <jar>SimpleApp.jar</jar>
  <outfile>..\SimpleApp.exe</outfile>
  <errTitle>SimpleApp</errTitle>
  <chdir>.</chdir>
  <downloadUrl></downloadUrl>
  <supportUrl></supportUrl>
  <jre>
    <path>%JAVA_HOME%</path>
  </jre>
</launch4jConfig>

If you have downloadUrl set then it will popup what ever ancient site you put there, but I'm guessing as you have not posted your configuration. If you don't set it you will get the error popup that there is no java installed (in case of GUI application and console error in case of console ones).

I also have JAVA_HOME pointing to OpenJDK 17. But when I run the resulting foobar.exe file, it pops up a page to java.com/download. So that's completely broken.

It's not broken.
minVersion and maxVersion work only with the registry keys, if the installer did not add them they do not affect the search.

Currently when using %JAVA_HOME% launch4j will use any Java version found there, regardless of minVersion/maxVersion.
But maybe this will change and the minVersion will be checked.

You have to remember that setting of JAVA_HOME is also optional in case of Adoptium installers. By default java is added to the PATH variable, but not JAVA_HOME.

Therefore a much better option might be:

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

This will first look in JAVA_HOME, then try to locate java on the PATH. But still the minVersion has no effect.

And finally launch4j was never intended as a tool for creating single file executables that can be run without installation. Some users use it this way in combination with other tools, but this is not the main goal of this project.

Grzegorz

[Garret Wilson]

Grzegorz, thanks for your reply.

… you have not posted your configuration

Yes I did; it was that parent POM I linked to above. Child projects merely enable it by specifying an .exe filename. It makes it very easy for child projects to add an executable.

If you have downloadUrl set then it will popup what ever ancient site you put there …

That's helpful, thanks! It looks like the launch4j-maven-plugin has a configuration default of http://java.com/download for this field. So maybe if I set it to empty as you show above it won't pop up the browser? (Or maybe I'll go all out and set it to the Adoptium URL, although I'm not yet convinced that the user like a CLI popping up a browser.)

You have to remember that setting of JAVA_HOME is also optional in case of Adoptium installers.

Yes; in fact I was going off the assumption that the user would probably forget anyway. The point here is that 1) it's 20 times easier to explain to the user how to set and verify JAVA_HOME instead of trying to get them to muck around with the registry, and 2) the best-practices convention for the past decade or more has been to look at JAVA_HOME, not read the registry. (How many tools, e.g. Maven, rely on JAVA_HOME? And how many rely on the registry being set? I can't even think of any modern tools that look at the registry!)

Anyway thanks for these clarifications. I'll digest them and decide whether Launch4J brings extra value or whether I'll just use an foobar-exe.jar/foobar.bat combination.

[Grzegorz Kowal]

Sorry, I missed the config file.

You're welcome. Regarding the download url - I see now that this a default
in launch4j :) I'll will remove as in fact today this default is not very
useful.

The registry was useful when launch4j was developed initially because all
JRE/JDK installers would add the key. To answer what program has used it -
java did itself so that the java.exe and javaw.exe launchers could find its
runtime (one of the methods used). So that was not some crazy idea to
follow this approach in launch4j.

The game has changed when 1.8 became the last version freely available and
OpenJdk started to become the main version used and Adopt or Adoptium
probably the favorite choice. At this point the registry search started to
deteriorate because their installers would not adds the keys or make it
optional, but still most of the user would have the original runtimes
installed.

Obviously more and more users will switch to Adoptium so in fact the
registry search will yield no results more often. I agree that it no longer
makes sense to support it in favor to another idea that I have that will
allow to specify the min/max java version.

Until that time the configuration posted above (%JAVA_HOME%;%PATH%) will
give best results, only the version cannot be controlled.

And of course if a simple batch solves your case, then maybe it's a better option and one dependency less.

Grzegorz

On Sun, Aug 7, 2022, 17:25 Garret Wilson garretwilson@users.sourceforge.net
wrote:

Grzegorz, thanks for your reply.

… you have not posted your configuration

Yes I did; it was that parent POM
https://raw.githubusercontent.com/globalmentor/globalmentor-root/c31ae410143f86ebf2bf10467214214d87b2eb61/pom.xml
I linked to above. Child projects merely enable it by specifying an .exe
filename. It makes it very easy for child projects to add an executable.

If you have downloadUrl set then it will popup what ever ancient site you
put there …

That's helpful, thanks! It looks like the launch4j-maven-plugin has a configuration
default http://launch4j.sourceforge.net/docs.html#Configuration_file of
http://java.com/download for this field. So maybe if I set it to empty as
you show above it won't pop up the browser? (Or maybe I'll go all out and
set it to the Adoptium URL, although I'm not yet convinced that the user
like a CLI popping up a browser.)

You have to remember that setting of JAVA_HOME is also optional in case of
Adoptium installers.

Yes; in fact I was going off the assumption that the user would probably
forget anyway. The point here is that 1) it's 20 times easier to explain to
the user how to set and verify JAVA_HOME instead of trying to get them to
muck around with the registry, and 2) the best-practices convention for the
past decade or more has been to look at JAVA_HOME, not read the registry.
(How many tools, e.g. Maven, rely on JAVA_HOME? And how many rely on the
registry being set? I can't even think of any modern tools that look at the
registry!)

Anyway thanks for these clarifications. I'll digest them and decide
whether Launch4J brings extra value or whether I'll just use an
foobar-exe.jar/foobar.bat combination.

---

• [bugs:#197] https://sourceforge.net/p/launch4j/bugs/197/ openJDK 11
  not detected*

Status: closed-fixed
Group: 3.x
Created: Wed Jan 02, 2019 03:23 PM UTC by lin83
Last Updated: Sun Aug 07, 2022 07:06 AM UTC
Owner: Grzegorz Kowal
Attachments:

• java_version.png
  https://sourceforge.net/p/launch4j/bugs/197/attachment/java_version.png
  (6.2 kB; image/png)

Hi Grzegors,

first of all, many thanks for your hard work on this tool.

As you know, Oracle has changed their license policy and moe and more of
my clients are using OpenJDK.
As openJDK comes with a zip file, without installed, it does not generate
any registry keys.

We have set the JAVA_HOME variable and even when calling java-version from
the command line we can see, openJDK and version 11.0.1.

But if I use the application converted as exe., I get the following error:
This application requires a Java Runtime Environment 11.0.1.

Does not matter if I select JRE, JDK or private jdk as launch4j setting.

Is there any additional setting to detect the java version based on the
Java_Home variable?

Any way you could help analyzing it?
I am using launch4j 3.12

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/launch4j/bugs/197/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Björn Kautler]

A few ct by me:

1) it's 20 times easier to explain to the user how to set and verify JAVA_HOME instead of trying to get them to muck around with the registry,

That's actually not really correct, because it is much easier to tell the user "install Java" or "reinstall Java" than to teach him how to set an environment variable and that he has to at least log out and back in after setting it for Windows to properly pick it up in all situations. This is not a guess from my side, but experience from talking to uses for 20 years.

2) the best-practices convention for the past decade or more has been to look at JAVA_HOME, not read the registry. (How many tools, e.g. Maven, rely on JAVA_HOME? And how many rely on the registry being set? I can't even think of any modern tools that look at the registry!)

That's not really correct.
It is best-practice for long that start scripts of tools look at JAVA_HOME and then trying to use Java from PATH.
Actually by using Java from PATH it often looked into registry, because there is java.exe and javaw.exe in the Windows directory that is in the path and then those executables look into the registry to find the installed Java versions that could be launched, and any tool using Launch4j usually also looks into the registry. So even if you personally are not aware, there are many cases where only one of them or also both are checked.

Actually, best practice and how the creators of Java intend it to be used would now be to bundle the JRE with your software, optimally before minified to what your program actually needs using JLink. (While I personally am not sure yet whether I like the new or old way better)

Anyway thanks for these clarifications. I'll digest them and decide whether Launch4J brings extra value or whether I'll just use an foobar-exe.jar/foobar.bat combination.

Of course it does. You have a proper entry in the task manager that you can easily identify, you have an icon, you can easily use it as target for file extension linking, and several others I don't have in mind right now.

I'll will remove as in fact today this default is not very useful.

That old page is not helpful for quite some time already. But I'd suggest to maybe use a more up-to-date download page as default instead of removing the default.

The registry was useful when launch4j was developed initially because all JRE/JDK installers would add the key. To answer what program has used it - java did itself so that the java.exe and javaw.exe launchers could find its runtime (one of the methods used). So that was not some crazy idea to follow this approach in launch4j.

The game has changed when 1.8 became the last version freely available and OpenJdk started to become the main version used and Adopt or Adoptium probably the favorite choice.

This did not change the game at all.

At this point the registry search started to deteriorate because their installers would not adds the keys or make it optional, but still most of the user would have the original runtimes installed.

The installers still add registry keys.
I'm not fully sure whether they are located somewhere else, or whether they are the same, but the registry search would still be a preferable way to find a compatible JRE. Maybe you have to update / add to the keys that are searched if they changed.

Obviously more and more users will switch to Adoptium so in fact the registry search will yield no results more often. I agree that it no longer makes sense to support it in favor to another idea that I have that will allow to specify the min/max java version.

I disagree to that as described above. :-)