127.5 Windows Launcher bit-ness warning

[Aleksandr Krymskiy]

Fresh Windows 10 VM - installed Oracle JDK 64 16.0.1. Getting "The Java run-time .. is a 32-bit Java" from SQLWorkbench64.exe. SQLWorkbench.exe does not start at all. Clicking the sqlworkbench.jar starts the app and it works as expected.  Nothing in path except the location JDK added: C:\Program Files\Common Files\Oracle\Java\javapath.

Never encountered this at all - seems strange - thought I'd post it here.

Thanks,

Alex

[Thomas Kellerer]

Hmm, strange.

I tried with Oracle's JDK but I cannot reproduce this.

Is the location of the JDK resolved through JAVA_HOME or through the PATH variable?

What does "where java" return?

There were no changes to the way the JDK is searched for between 127.4 and 127.5.

One difference is, that parameter for Java 16 is passed correctly.

What happens if you run SQL Workbench manually using

"c:\Program Files\Common Files\Oracle\Java\bin\java.exe" --add-opens java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED -jar sqlworkbench.jar


Can you also start the launcher with the command line parameter -logstartup please?
Maybe I can see something in the logfile.

Thomas

> sql_java.png

[Aleksandr Krymskiy]

Java is resolved via PATH by the javapath symlink that Oracle JDK installed. I have not set or changed any environment variables. This is a clean Win 10 VM with Oracle JDK 64 16.0.1 (jdk-16.0.1_windows-x64_bin.exe) installed and SQL Workbench 127.5 extracted - I need a separate environment because my workplace uses a weird VPN that wrecks havoc on the routing tables, so I isolated it to VM to avoid messing with other connectivity on my workstation.

Just double clicking the sqlworkbench.jar or issuing command like you suggested (after correcting the path to Java) - launches Workbench just fine, so only the launcher is affected. I attached screenshots of the commands as requested; nothing particular in the log, SQLWorkbench64.exe just doesn't recognize the Java as a 64-bit Java, despite it being a 64-bit machine with a single install of 64-bit JDK...

I also tried running SQLWorkbench.exe with -logstartup just for kicks and including that output also.

[Thomas Kellerer]

Ah, I see.

When using the java.exe from the path, I am resolving the path to the .dll incorrectly.
Thanks for the feedback, I will fix that.

For the time being, you can configure your Java Home using sqlworkbench.cfg using

[Workbench]
JavaHome=c:\Program Files\Common Files\Oracle\Java


(You can e.g. copy SQLWorkbench.cfg.sample to SQLWorkbench.cfg)

Then the launcher will pick it up correctly.


Regards
Thomas

Aleksandr Krymskiy schrieb am 20.05.2021 um 05:05:
> Java is resolved via PATH by the javapath symlink that Oracle JDK installed. I have not set or changed any environment variables. This is a clean Win 10 VM with Oracle JDK 64 16.0.1 (jdk-16.0.1_windows-x64_bin.exe) installed and SQL Workbench 127.5 extracted - I need a separate environment because my workplace uses a weird VPN that wrecks havoc on the routing tables, so I isolated it to VM to avoid messing with other connectivity on my workstation.
> Just double clicking the sqlworkbench.jar or issuing command like you suggested (after correcting the path to Java) - launches Workbench just fine, so only the launcher is affected. I attached screenshots of the commands as requested; nothing particular in the log, SQLWorkbench64.exe just doesn't recognize the Java as a 64-bit Java, despite it being a 64-bit machine with a single install of 64-bit JDK...
> I also tried running SQLWorkbench.exe with -logstartup just for kicks and including that output also.
>
>

> sql_java2.png
> sql_java3.png
> sql_java4.png

> sql_java5.png
> On Tuesday, May 18, 2021 at 1:14:38 PM UTC-4 Thomas Kellerer wrote:
>
> Hmm, strange.
>
> I tried with Oracle's JDK but I cannot reproduce this.
>
> Is the location of the JDK resolved through JAVA_HOME or through the PATH variable?
>
> What does "where java" return?
>
> There were no changes to the way the JDK is searched for between 127.4 and 127.5.
>
> One difference is, that parameter for Java 16 is passed correctly.
>
> What happens if you run SQL Workbench manually using
>
> "c:\Program Files\Common Files\Oracle\Java\bin\java.exe" --add-opens java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED -jar sqlworkbench.jar
>
>
> Can you also start the launcher with the command line parameter -logstartup please?
> Maybe I can see something in the logfile.
>
> Thomas
>
>
> Aleksandr Krymskiy schrieb am 17.05.2021 um 22:43:
> > Fresh Windows 10 VM - installed Oracle JDK 64 16.0.1. Getting "The Java run-time .. is a 32-bit Java" from SQLWorkbench64.exe. SQLWorkbench.exe does not start at all. Clicking the sqlworkbench.jar starts the app and it works as expected.  Nothing in path except the location JDK added: C:\Program Files\Common Files\Oracle\Java\javapath.
> > Never encountered this at all - seems strange - thought I'd post it here.
> >
> > Thanks,
> > Alex
> >
> > sql_java.png
>

> --
> You received this message because you are subscribed to the Google Groups "SQL Workbench/J - DBMS independent SQL tool" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sql-workbenc...@googlegroups.com <mailto:sql-workbenc...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sql-workbench/bc32658f-18c2-4391-bbab-87f2fe02ff02n%40googlegroups.com <https://groups.google.com/d/msgid/sql-workbench/bc32658f-18c2-4391-bbab-87f2fe02ff02n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Thomas Kellerer]

Just to be sure:

Your symlink: "c:\Program Files\Common Files\Oracle\Java\javapath" points to "c:\Program Files\Common Files\Oracle\Java\bin"

Right?

My launcher assumes a standard directory layout, where the .exe is located in the "bin" subdirectory of the Java home.
That's why it doesn't recognize it properly.
The error message could be better though ;)

Thomas

[Aleksandr Krymskiy]

The symlink actually refers to javapath_target_29609703 within the same folder. There are 4 executables in it, each 645KB. They are all Oracle installed/digitally signed files. When I look at the properties it says Original filename: shimconsole.exe - so I guess this is some new-ish thing that Oracle has come up with to manage the path to Java - I wasn't able to find much official info and I am personally confused about how these end up launching the actual binaries in the JDK bin folder....

I suppose this is what makes the launcher confused about the bitness; however the .exe are still reporting 64-bit according to sigcheck.

[Thomas Kellerer]

As I said: the error message is misleading.

The launcher expects "java.exe" to be in a directory "bin" and then tries to find the .dll from there.

As in your case the java.exe is found in a different directory, the launcher gets confused doesn't find the .dll and the check actually returns an error code. That error code is treated as "not 64bit" - and that's the reason for the error message.

I recommend to either specify the JAVA_HOME environment variable pointing to "c:\Program Files\Common Files\Oracle\Java", or specifying the Java home in SQLWorkbench.cfg to avoid this.

Thomas

Aleksandr Krymskiy schrieb am 24.05.2021 um 22:54:
> The symlink actually refers to javapath_target_29609703 within the same folder. There are 4 executables in it, each 645KB. They are all Oracle installed/digitally signed files. When I look at the properties it says Original filename: shimconsole.exe - so I guess this is some new-ish thing that Oracle has come up with to manage the path to Java - I wasn't able to find much official info and I am personally confused about how these end up launching the actual binaries in the JDK bin folder....
> I suppose this is what makes the launcher confused about the bitness; however the .exe are still reporting 64-bit according to sigcheck.
>

> sql_java6.png

> To view this discussion on the web visit https://groups.google.com/d/msgid/sql-workbench/e8f32a39-f924-4a42-abbc-e2fd24c398c1n%40googlegroups.com <https://groups.google.com/d/msgid/sql-workbench/e8f32a39-f924-4a42-abbc-e2fd24c398c1n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Nguyen Duong Vu]

I had exactly the same issue with my new laptop. Setting the javaHome point to JDK location works for me as suggested.

Thanks, guys!