In 3.8 the Java version checker is not finding any Java version on my system. 3.7 does.
Debug log of 3.7:
Resource 2: 1.7.0
Resource 18: 1
Resource 30: 2
64-bit search: SOFTWARE\JavaSoft\Java Runtime Environment...
Check: SOFTWARE\JavaSoft\Java Runtime Environment\1.8
Check launcher: C:\Program Files\Java\jre1.8.0_91\bin\javaw.exe (OK)
Match: 1.8
Check: SOFTWARE\JavaSoft\Java Runtime Environment\1.8.0_91
Check launcher: C:\Program Files\Java\jre1.8.0_91\bin\javaw.exe (OK)
Match: 1.8.0_91
64-bit search: SOFTWARE\JavaSoft\Java Development Kit...
Check: SOFTWARE\JavaSoft\Java Development Kit\1.8
Ignore: 1.8
Check: SOFTWARE\JavaSoft\Java Development Kit\1.8.0_77
Ignore: 1.8.0_77
Runtime used: 1.8.0_91 (64-bit)
Resource 20: 32
Resource 17: true
Launcher: C:\Program Files\Java\jre1.8.0_91\bin\javaw.exe
Output of 3.8 gives no "Check" lines at all.
Ticket moved from /p/launch4j/bugs/150/
Ticket moved from /p/launch4j/feature-requests/105/
This is quite strange as there were no changes in the search between these two versions. Actually there was only one minor change in the headers. Can you post both logs (complete) from 3.7 and 3.8?
I'm seeing something similar: a dialog saying "This application requires a Java Runtime Environment 1.7.0".
Here's Java:
I've attached my log file.
My config:
Last edit: Dan Gravell 2016-11-01
Thanks!
Can you update the file head.o in head directory of launch4j and build the launcher once again? Then run it with the --l4j-debug-all option, it will now log some more information that will allow to confirm where the problem is.
Best regards,
Grzegorz
There's not much extra info, where you expecting more?
No, this helped to rule out one of the causes. I've added some more logging, can you try it once again?
The reason seems to be a missing resource or failure to load the runtime bits which is then ignored and treated as if the correct version was not installed.
Additionally could you check with resource hacker that the output executable contains resource 30 and post it's value? So that I know if it's a bug in the building process or in the launcher.
Alternatively you can attach the exe here.
Best regards,
Grzegorz
There is no resource 30 in resource hacker...
Thanks, so now I have to find the problem in the builder.
Can you try building the launcher with the attached version of lauch4j? This is basically 3.9 which will output the resource file. It would be great if you could post it here. I see no changes in code from 3.7 that could break it. Only one is related to the file encoding but it would be quite strange. Anyhow this would prove that the problem lies only in the resource compilation.
Thanks,
Grzegorz
Here's what I get on build:
At launch:
Err... and it appears to have worked now.
I'm confused, was I running with the incorrect JAR?
Based on the log that you attached, the jar was correct - version 3.9.
It works because the resource that was previously missing was now added, and so I still cannot tell if the problem is in launch4j or windres.
If you still have some energy to help me find the cause :) you can try using the orignial jar from the release 3.9 to see if this is a random problem or always happens.
Unfortunatelly I cannot see the reason for not creating the problematic resource 30, especially I cannot find the difference between ver. 3.7 and 3.9 other then the file encoding.
Grzegorz
Sure, I want to get this fixed!
Not sure if I said, but this is running in the Ant build on Linux, Xubuntu 16.04.
Hmmm. In my build environment I have just bin, head, lib and w32api. launch4j.jar is inside lib... not the root, as it is in the latest released launch4j distribution. Can't see how that would be a problem so long as it's on the classpath. I note it's still just launch4j and xstream on the classpath, and not any of the other new JARs added in recent releases.
I re-ran with the latest release and it works fine now.
Might I have just made a mistake?
From your first post I saw that the version of launch4j was correct (launch4j.log), so I don't think you could mistakenly have used a different version of launch4j. The problem here is that one of the resources is not added to the exe either because it is not in the resource file created by launch4j or because there is a problem with windres. It's not something you can configure incorrectly. Right now the only thing you can do is to use the attached jar with resource logging. If the problem happens again it will be immediately visible if the problem is in the launch4j resource builder.
The good news is that because it is a reasource problem, once you test the output launcher you can be sure it will work correctly. So the randomness is in the building process and not the executable itself.
Grzegorz
Ok, I'll go back to the patch above for now then...
I just ran into this problem as well and I wanted to make a suggestion. I have a 32 bit version of java installed on a 64 bit laptop. Because of this, the registry location for the Java Runtime Environment is HKLM\Software\Wow6432Nod\JavaSoft, not HKLM\Software\JavaSoft as it would be for 64 bit java installed on a 64 bit machine. Maybe launch4j only checks HKLM\Software\JavaSoft for the current version of java installed?
Technically this is true, but applications should rather access the 32-bit or 64-bit views of the registry using a special flag. This is how it is done by launch4j, therefore it will always use the HKLM\Software\JavaSoft key and redirect to the proper view. So you will not see the Wow6432 key in the logs although it is accessed. This is quite useful as you don't have to change all the registry keys.
And of course this was tested, on a 64-bit machine you can use both 32-bit and 64-bit JREs.
If you have the same problem, it is the missing resource, you can say that the output executable is configured incorrectly.
Could you use the head.o (later version) and launch4j.jar attached in this bug and post the output from launch4j and the output exec with --l4j-debug-all?
Thanks for the input,
Grzegorz
Releasing the extra logging in 3.10 for now, and switching to closed as the problem is not directly in l4j.