Menu

#151 3.8 the Java version checker is not finding any Java version

3.x
closed-postponed
None
5
2017-05-31
2016-07-12
No

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.

Discussion

  • Grzegorz Kowal

    Grzegorz Kowal - 2016-07-12

    Ticket moved from /p/launch4j/bugs/150/

     
  • Grzegorz Kowal

    Grzegorz Kowal - 2016-07-12

    Ticket moved from /p/launch4j/feature-requests/105/

     
  • Grzegorz Kowal

    Grzegorz Kowal - 2016-07-20

    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?

     
  • Dan Gravell

    Dan Gravell - 2016-11-01

    I'm seeing something similar: a dialog saying "This application requires a Java Runtime Environment 1.7.0".

    Here's Java:

    C:\temp>java -version
    java version "1.8.0_66"
    Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
    Java HotSpot(TM) Client VM (build 25.66-b17, mixed mode)
    

    I've attached my log file.

    My config:

        <launch4j bindir="${launch4j.dir}/bin">
            <config dontWrapJar="true" headerType="gui" downloadUrl="http://java.com/download" outfile="${release.bin.dir}/bliss.exe" chdir="." customProcName="true" stayAlive="false">
                <classPath mainClass="org.apache.felix.main.Main">
                    <cp>..\bin\felix.jar</cp>
                </classPath>
                <jre minVersion="1.7.0"/>
                <splash file="${release.bin.dir}/bliss-splash.bmp" waitForWindow="false" timeout="5" timeoutErr="false"/>
                <singleInstance mutexName="bliss" />
                <obj>../w32api/crt2.o</obj>
                <obj>../head/guihead.o</obj>
                <obj>../head/head.o</obj>
                <lib>../w32api/libmingw32.a</lib>
                <lib>../w32api/libgcc.a</lib>
                <lib>../w32api/libmsvcrt.a</lib>
                <lib>../w32api/libkernel32.a</lib>
                <lib>../w32api/libuser32.a</lib>
                <lib>../w32api/libadvapi32.a</lib>
                <lib>../w32api/libshell32.a</lib>
            </config>
        </launch4j>
    
     

    Last edit: Dan Gravell 2016-11-01
  • Grzegorz Kowal

    Grzegorz Kowal - 2016-11-03

    Thanks!

     
  • Grzegorz Kowal

    Grzegorz Kowal - 2016-11-03

    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

     
  • Grzegorz Kowal

    Grzegorz Kowal - 2016-11-03
    • assigned_to: Grzegorz Kowal
     
  • Dan Gravell

    Dan Gravell - 2016-11-04

    There's not much extra info, where you expecting more?

    Version:    3.9
    CmdLine:    C:\Program Files\bliss\bin\bliss.exe --l4j-debug-all
    WOW64:      no
    Resource 101:   An error occurred while starting the application.
    Resource 23:    bliss
    Create mutex:   bliss
    Resource 8: .
    Working dir:    C:\Program Files\bliss\bin\.
    jreSearch()
    Resource 2: 1.7.0
    Java min ver:   1.7.0
    Java max ver:   
    bundledJreSearch()
    installedJreSearch()
    Resource 18:    1
    findJavaHome()
    Resource 103:   This application requires a Java Runtime Environment
    Resource 21:    http://java.com/download
    Error msg:  This application requires a Java Runtime Environment 1.7.0
    Open URL:   http://java.com/download
    
     
  • Grzegorz Kowal

    Grzegorz Kowal - 2016-11-07

    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

     
  • Dan Gravell

    Dan Gravell - 2016-11-08
    Version:    3.9
    CmdLine:    C:\Program Files\bliss\bin\bliss.exe --l4j-debug-all
    WOW64:      no
    Resource 10:    <NULL>
    Resource 22:    <NULL>
    Resource 101:   An error occurred while starting the application.
    Resource 23:    bliss
    Create mutex:   bliss
    Resource 8: .
    Working dir:    C:\Program Files\bliss\bin\.
    jreSearch()
    Resource 32:    <NULL>
    Resource 2: 1.7.0
    Java min ver:   1.7.0
    Resource 3: <NULL>
    Java max ver:   
    bundledJreSearch()
    Resource 1: <NULL>
    installedJreSearch()
    Resource 18:    1
    findJavaHome()
    Resource 30:    <NULL>
    Runtime bits:   Failed to load.
    Runtime bits:   Failed to load.
    Runtime bits:   Failed to load.
    Runtime bits:   Failed to load.
    Resource 103:   This application requires a Java Runtime Environment
    Resource 21:    http://java.com/download
    Error msg:  This application requires a Java Runtime Environment 1.7.0
    Open URL:   http://java.com/download
    

    There is no resource 30 in resource hacker...

     
  • Grzegorz Kowal

    Grzegorz Kowal - 2016-11-08

    Thanks, so now I have to find the problem in the builder.

     
  • Grzegorz Kowal

    Grzegorz Kowal - 2016-11-14

    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

     
  • Dan Gravell

    Dan Gravell - 2016-11-15

    Here's what I get on build:

     [launch4j] Resource file:
     [launch4j] LANGUAGE 0, 1
     [launch4j] 2 RCDATA BEGIN "1.7.0\0" END
     [launch4j] 18 RCDATA BEGIN "1\0" END
     [launch4j] 30 RCDATA BEGIN "2\0" END
     [launch4j] 21 RCDATA BEGIN "http://java.com/download\0" END
     [launch4j] 8 RCDATA BEGIN ".\0" END
     [launch4j] 20 RCDATA BEGIN "32\0" END
     [launch4j] 4 RCDATA BEGIN "true\0" END
     [launch4j] 6 RCDATA BEGIN "5\0" END
     [launch4j] 1 BITMAP "/home/gravelld/eclipse-workspaces/bliss/com.elsten.bliss.installer/release/bin/bliss-splash.bmp"
     [launch4j] 101 RCDATA BEGIN "An error occurred while starting the application.\0" END
     [launch4j] 102 RCDATA BEGIN "This application was configured to use a bundled Java Runtime Environment but the runtime is missing or corrupted.\0" END
     [launch4j] 103 RCDATA BEGIN "This application requires a Java Runtime Environment\0" END
     [launch4j] 104 RCDATA BEGIN "The registry refers to a nonexistent Java Runtime Environment installation or the runtime is corrupted.\0" END
     [launch4j] 105 RCDATA BEGIN "An application instance is already running.\0" END
     [launch4j] 23 RCDATA BEGIN "bliss\0" END
     [launch4j] 15 RCDATA BEGIN "org.apache.felix.main.Main\0" END
     [launch4j] 16 RCDATA BEGIN "..\\bin\\felix.jar\0" END
     [launch4j] Compiling resources
     [launch4j] Linking
     [launch4j] Successfully created /home/gravelld/eclipse-workspaces/bliss/com.elsten.bliss.installer/release/bin/bliss.exe
    

    At launch:

    Version:    3.9
    CmdLine:    C:\Program Files\bliss\bin\bliss.exe --l4j-debug-all
    WOW64:      no
    Resource 10:    <NULL>
    Resource 22:    <NULL>
    Resource 101:   An error occurred while starting the application.
    Resource 23:    bliss
    Create mutex:   bliss
    Resource 8: .
    Working dir:    C:\Program Files\bliss\bin\.
    jreSearch()
    Resource 32:    <NULL>
    Resource 2: 1.7.0
    Java min ver:   1.7.0
    Resource 3: <NULL>
    Java max ver:   
    bundledJreSearch()
    Resource 1: <NULL>
    installedJreSearch()
    Resource 18:    1
    findJavaHome()
    Resource 30:    2
    32-bit search:  SOFTWARE\JavaSoft\Java Runtime Environment...
    Check:      SOFTWARE\JavaSoft\Java Runtime Environment\1.8
    Check launcher: C:\Program Files\Java\jre1.8.0_66\bin\javaw.exe (OK)
    Match:      1.8
    Check:      SOFTWARE\JavaSoft\Java Runtime Environment\1.8.0_66
    Check launcher: C:\Program Files\Java\jre1.8.0_66\bin\javaw.exe (OK)
    Match:      1.8.0_066
    32-bit search:  SOFTWARE\JavaSoft\Java Development Kit...
    Runtime used:   1.8.0_066 (32-bit)
    Resource 19:    <NULL>
    Resource 20:    32
    Resource 25:    <NULL>
    Resource 26:    <NULL>
    Resource 27:    <NULL>
    Resource 28:    <NULL>
    Resource 12:    <NULL>
    Loading:    C:\Program Files\bliss\bin\bliss.l4j.ini
    Substitute: EXEDIR = C:\Program Files\bliss\bin
    Substitute: EXEDIR = C:\Program Files\bliss\bin
    Substitute: EXEFILE = C:\Program Files\bliss\bin\bliss.exe
    Substitute: HomeDrive = C:
    Substitute: HomePath = \Users\gravelld
    Substitute: EXEDIR = C:\Program Files\bliss\bin
    Substitute: TEMP = C:\Users\gravelld\AppData\Local\Temp
    Resource 17:    <NULL>
    Resource 14:    <NULL>
    Resource 15:    org.apache.felix.main.Main
    Main class: org.apache.felix.main.Main
    Resource 16:    ..\bin\felix.jar
    Add classpath:  ..\bin\felix.jar
    Resource 13:    <NULL>
    Launcher:   C:\Program Files\Java\jre1.8.0_66\bin\javaw.exe
    Launcher args:  -Xmx256M -Djetty.home.bundle=com.elsten.bliss.jetty -Dfelix.auto.deploy.dir="C:\Program Files\bliss\bin\\..\\bundle" -Dbliss.bootstrapbundle.initialbundledir="C:\Program Files\bliss\bin\\..\\bliss-bundle" -Dbliss.launcher="C:\Program Files\bliss\bin\bliss.exe" -Dorg.osgi.framework.storage="C:\Users\gravelld\\.bliss\\felix-cache" -Djava.util.logging.config.file="C:\Program Files\bliss\bin\\..\\conf\\logging.properties" -Drun.mode=production -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath="C:\Users\gravelld\AppData\Local\Temp" -XX:+CMSClassUnloadingEnabled -classpath "..\bin\felix.jar" org.apache.felix.main.Main
    Args length:    618/32768 chars
    Resource 4: true
    Resource 31:    <NULL>
    Resource 11:    <NULL>
    Resource 6: 5
    Resource 7: <NULL>
    Resource 5: <NULL>
    Exit code:  259
    

    Err... and it appears to have worked now.

    I'm confused, was I running with the incorrect JAR?

     
  • Grzegorz Kowal

    Grzegorz Kowal - 2016-11-16

    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

     
  • Dan Gravell

    Dan Gravell - 2016-11-17

    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?

     
  • Grzegorz Kowal

    Grzegorz Kowal - 2016-11-17

    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

     
  • Dan Gravell

    Dan Gravell - 2016-11-18

    Ok, I'll go back to the patch above for now then...

     
  • Michael

    Michael - 2016-11-21

    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?

     
  • Grzegorz Kowal

    Grzegorz Kowal - 2016-11-22

    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

     
  • Grzegorz Kowal

    Grzegorz Kowal - 2017-05-31
    • status: open --> closed-postponed
     
  • Grzegorz Kowal

    Grzegorz Kowal - 2017-05-31

    Releasing the extra logging in 3.10 for now, and switching to closed as the problem is not directly in l4j.

     

Log in to post a comment.