Discussions
Categories
- 385.5K All Categories
- 5.1K Data
- 2.5K Big Data Appliance
- 2.5K Data Science
- 453.4K Databases
- 223.2K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 47 Multilingual Engine
- 606 MySQL Community Space
- 486 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3.2K ORDS, SODA & JSON in the Database
- 584 SQLcl
- 4K SQL Developer Data Modeler
- 188K SQL & PL/SQL
- 21.5K SQL Developer
- 46 Data Integration
- 46 GoldenGate
- 298.4K Development
- 4 Application Development
- 20 Developer Projects
- 166 Programming Languages
- 295K Development Tools
- 150 DevOps
- 3.1K QA/Testing
- 646.7K Java
- 37 Java Learning Subscription
- 37.1K Database Connectivity
- 201 Java Community Process
- 108 Java 25
- 22.2K Java APIs
- 138.3K Java Development Tools
- 165.4K Java EE (Java Enterprise Edition)
- 22 Java Essentials
- 176 Java 8 Questions
- 86K Java Programming
- 82 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 208 Java User Groups
- 25 JavaScript - Nashorn
- Programs
- 666 LiveLabs
- 41 Workshops
- 10.3K Software
- 6.7K Berkeley DB Family
- 3.6K JHeadstart
- 6K Other Languages
- 2.3K Chinese
- 207 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 474 Portuguese
JAVA_HOME on Windows

Hi,
Why does SQLcl on Windows not use JAVA_HOME as the version of Java to use if it's set? I assumed it did this or used the PATH initially to identify the location of java.exe to use.
Looking at the debug output when running SQLcl I can see it checks the following:
Paths:
..\..\jdk\jre\bin\java.exe
Registry keys:
64-bit search: SOFTWARE\JavaSoft\Java Runtime Environment...
32-bit search: SOFTWARE\JavaSoft\Java Runtime Environment...
64-bit search: SOFTWARE\JavaSoft\Java Development Kit...
32-bit search: SOFTWARE\JavaSoft\Java Development Kit...
64-bit search: SOFTWARE\JavaSoft\JRE...
32-bit search: SOFTWARE\JavaSoft\JRE...
64-bit search: SOFTWARE\JavaSoft\JDK...
32-bit search: SOFTWARE\JavaSoft\JDK...
64-bit search: SOFTWARE\IBM\Java Runtime Environment...
32-bit search: SOFTWARE\IBM\Java Runtime Environment...
64-bit search: SOFTWARE\IBM\Java Development Kit...
32-bit search: SOFTWARE\IBM\Java Development Kit...
64-bit search: SOFTWARE\IBM\Java2 Runtime Environment...
32-bit search: SOFTWARE\IBM\Java2 Runtime Environment...
64-bit search: SOFTWARE\IBM\Java Development Kit...
32-bit search: SOFTWARE\IBM\Java Development Kit...
But never JAVA_HOME or PATH, why?
Incidentally this caused me quite a bit of head scratching to work out why my installation was not working.
David.
Best Answer
-
That second link I posted above talks about how the SQL Developer team uses Launch4j - Cross-platform Java executable wrapper to build it's exe files. I assume the way they configure it, if no JRE is found at ..\..\jdk\jre relative to the location of sql.exe, then Launch4J searches for the highest Java JRE installed on your machine.
That behavior can definitely make life tougher, leading you to add a JRE inside the SQLcl install at ..\..\jdk\jre relative to the location of sql.exe as a last resort. Otherwise, I suppose you could try to create your own sql.bat file to behave like the bash script for Linux, but few will want to bother with that.
Edit: If you do, start with this 18.1 version hack in and make any necessary changes for it to work with SQLcl 20.2.
Answers
-
Take a minute to read through a couple of prior discussions:
Re: Java limitation:lower versions of SQLCL available? -- This describes some general rules for how SQLcl finds the JRE under Windows and Linux.
and
Re: unable to launch SQLCL 18.1 -- This notes especially how one of the rules changed between 17.4 and 18.1, making sql.exe consistent with sqldeveloper.exe
Hope this helps!
-
Thanks @Glen Conway. One of those posts actually help me resolve the issue I was having originally. What I am interested in specifically here though is why the Windows exe does not use JAVA_HOME.
Is it just the assumption that on Windows, people don't use environment variables the same as on Linux?
-
That second link I posted above talks about how the SQL Developer team uses Launch4j - Cross-platform Java executable wrapper to build it's exe files. I assume the way they configure it, if no JRE is found at ..\..\jdk\jre relative to the location of sql.exe, then Launch4J searches for the highest Java JRE installed on your machine.
That behavior can definitely make life tougher, leading you to add a JRE inside the SQLcl install at ..\..\jdk\jre relative to the location of sql.exe as a last resort. Otherwise, I suppose you could try to create your own sql.bat file to behave like the bash script for Linux, but few will want to bother with that.
Edit: If you do, start with this 18.1 version hack in and make any necessary changes for it to work with SQLcl 20.2.
-
Which permission is required for https://community.oracle.com/message/14456937#14456937? I Can't read it.
-
I guess not all links got migrated properly when moving the Oracle Community from the Jive platform to the Vanilla open source platform. I used the Search feature to get the following. I had to quote them to avoid some substitution. I hope they work for you.
"https://community.oracle.com/tech/developers/discussion/comment/14835441#Comment_14835441"
"https://community.oracle.com/tech/developers/discussion/comment/14792180#Comment_14792180"
-
Indeed they do, thanks!