Garret Wilson

Charset problem in exe file description field.

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. Yes, and I think even "better" is the new JPackage that is on top of JLink. Believe me I'd love to do it that way. But if I understand it correctly, they designed it so you have to create the executable on the same platform as the target. In other words, if I'm generating a Windows installer, I have...

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...

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...

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...

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?

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...

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...