Philipp Salvisberg's Blog Database-centric development 2026-08-29T07:52:43Z https://www.salvis.com/blog/feed/atom/ WordPress https://www.salvis.com/blog/wp-content/uploads/2014/04/favicon.png Philipp Salvisberg http://www.salvis.com/ <![CDATA[Implicit Outer Joins in Join-to-One: Feature or Flaw?]]> https://www.salvis.com/blog/?p=23948 2026-08-29T07:52:43Z 2026-08-29T07:52:40Z Background As you probably know, I’m maintaining a parser for grammars used in SQL files for Oracle AI Database and PostgreSQL. As a result, I check for new statements and clauses in every version of those DBMSs. PostgreSQL typically adds new features only in major versions; this means yearly. Oracle, on the […]

The post Implicit Outer Joins in Join-to-One: Feature or Flaw? appeared first on Philipp Salvisberg's Blog.

]]> Background

As you probably know, I’m maintaining a parser for grammars used in SQL files for Oracle AI Database and PostgreSQL. As a result, I check for new statements and clauses in every version of those DBMSs. PostgreSQL typically adds new features only in major versions; this means yearly. Oracle, on the other hand, documents new features in every new RU; this means quarterly.

The RU for 26.2 was a bit delayed. So, on 1 May 2026, I went through the new features in 26.2 and discovered the join-to-one clause while documenting the changes required for IslandSQL in a GitHub issue. I tried the feature in an OCI instance and posted about it on Bluesky.

Join to one post on Bluesky

This led to some discussions in private channels.

Back then, I hadn’t made up my mind regarding the usefulness of this feature, but the fact that a join uses outer-join semantics by default irritated me from the very first moment.

In the meantime, I believe that this feature is useful for various use cases. I’m not going to talk about that in this blog post. However, the longer I thought about the implicit outer join in join-to-one, the more it irritated me.

Join-To-One Will Make It Into the SQL Standard

According to Peter Eisentraut’s blog post, this feature has been accepted into the next SQL standard and is now part of its working draft. I wonder whether they also discussed the default join behaviour of a join-to-one and what the consensus was.

Anyway, since version 26.2, this feature is part of Oracle AI Database. Changing the behaviour at that stage is only feasible with a database parameter similar to group_by_position_enabled to keep backward compatibility. I doubt that something like this will happen.

What Is the Problem?

It is the first time an outer join has become the default. For every other join variant since ANSI SQL-86, an inner join has been the default. We are used to that.

Changing such a long-established convention is not necessarily a bad thing. However, there should be a convincing reason for doing so.

The SQL Language Reference provides this reason:

“The database chose this default because INNER JOINs often filter rows unintentionally.”

So, the intention is to avoid accidental filtering. That sounds reasonable. But is silently preserving rows really better than silently filtering them?

In both cases, the omitted join type affects the result. An implicit inner join may remove rows. An implicit outer join may introduce null values that have to be considered in subsequent expressions and predicates.

In any case, the join-to-one clause relies on integrity constraints. These constraints are already used to derive the join condition. So why not consider them fully and choose an inner join for mandatory foreign keys and an outer join for optional foreign keys?

Of course, this would make the join type depend on the schema definition. A change to the optionality of a foreign key could then change the semantics of an existing query. That would have been a very good reason not to choose a fixed default join type, right?

However, while the optimiser could deal with a dynamically determined join type, the query would be more challenging to read and understand. We would need to check the current optionality of each foreign key involved to determine whether nulls need to be handled.

Ouch. This would be cumbersome without implementing an additional concept that forces us to handle null values in SQL expressions and predicates (something similar to JSpecify). Therefore, it’s probably better not to derive the join type automatically from a foreign key’s optionality. Being explicit has its value.

Furthermore, an outer join limits the optimiser’s solution space and can affect performance, as Andrej Pashchenko demonstrated for join-to-one in this blog post.

These performance aspects may be addressed in upcoming versions. But the unfamiliar implicit default join strategy remains.

An Example

Let’s compare the following two queries:

1) Implicit outer joins
select count(*)
  from employees e
  join to one (
          departments d,
          jobs j,
          employees mgr on e.manager_id 
                       = mgr.employee_id
       )
 where e.salary > mgr.salary;
2) Explict inner and outer joins
select count(*)
  from employees e
  join to one (
          outer join departments d
          inner join jobs j
          outer join employees mgr on e.manager_id 
                                  = mgr.employee_id
       )
 where e.salary > mgr.salary;

The queries are based on the HR example schema and produce the same result.

Which one is easier to read and understand?

Which one reveals information that might be helpful when crafting or reviewing the WHERE clause?

IMO, the second example. For both questions.

The second example shows that:

  • Employees do not necessarily belong to a department. Yes, the department_id column in the employees table is optional.
  • Not every employee has a manager.
  • Every employee has a job.

This information helps us filter data using the department or manager columns. We have to handle null values there.

Based on that, we can see a flaw in the query. We can either use an inner join for managers because we are not interested in counting employees without a manager, or we have to address employees without a manager in the WHERE clause.

So, we should change the query to something like the following:

2a) Excluding emps without mgr
select count(*)
  from employees e
  join to one (
          outer join departments d
          inner join jobs j
          inner join employees mgr on e.manager_id 
                                  = mgr.employee_id
       )
 where e.salary > mgr.salary;
2b) Including emps without mgr
select count(*)
  from employees e
  join to one (
          outer join departments d
          inner join jobs j
          outer join employees mgr on e.manager_id 
                                  = mgr.employee_id
       )
 where e.salary > mgr.salary
    or mgr.employee_id is null;

Query 2a produces the same result as queries 1 and 2, but the inner join on employees makes it clear that excluding employees without a manager was intended.

Query 2b produces additional results for employees without a manager. The outer join on employees and the null handling in the WHERE clause make it clear that this was intentional.

Summary

IMO, the implicit outer joins in the new join-to-one clause are clearly a flaw. You should always specify inner or outer joins explicitly in a join-to-one clause. This communicates the intended semantics and highlights where downstream null handling may be required.

If you are using dbLinter – which you should – then you can enable the rule G-3194 to improve the maintainability of your join-to-one clauses.

The post Implicit Outer Joins in Join-to-One: Feature or Flaw? appeared first on Philipp Salvisberg's Blog.

]]> 0 Philipp Salvisberg http://www.salvis.com/ <![CDATA[The Checkbox That Disables TLS]]> https://www.salvis.com/blog/?p=23591 2026-08-24T05:38:18Z 2026-08-23T21:20:28Z Introduction The dbLinter clients include a new setting named Allow Insecure TLS. It is disabled by default. As a result, all REST API calls verify the TLS certificate and hostname. The setting allows dbLinter to work in organisations that inspect TLS traffic using tools such as Zscaler. In larger organisations, arranging an […]

The post The Checkbox That Disables TLS appeared first on Philipp Salvisberg's Blog.

]]> Introduction

The dbLinter clients include a new setting named Allow Insecure TLS. It is disabled by default. As a result, all REST API calls verify the TLS certificate and hostname.

The setting allows dbLinter to work in organisations that inspect TLS traffic using tools such as Zscaler.

In larger organisations, arranging an inspection bypass can be cumbersome and is often too much effort for an ad-hoc trial of dbLinter. The checkbox provides a temporary workaround and should be enabled only on a trusted network.

However, allowing insecure TLS on untrusted networks, such as open Wi-Fi without client isolation, can let an attacker redirect traffic through their own machine using techniques like ARP spoofing. The attacker can also operate the access point themselves, for example, by creating a rogue Wi-Fi hotspot.

In this blog post, I demonstrate the effect of this checkbox.

Allow Insecure TLS

The latest version of dbLinter for VS Code has a checkbox that disables certificate and hostname verification.

Allow Insecure TLS Checkbox in VS Code

dbLinter’s allowInsecureTls setting is nothing unusual. Many common tools offer a similar option, including curl (--insecure), wget (--no-check-certificate), and git (--config http.sslVerify false).

Installing and Configuring a Proxy

I run this demo on macOS 26.6.2.

A simple proxy is mitmweb. We can install and configure it as follows:

brew install mitmproxy
networksetup -setsecurewebproxy "Wi-Fi" 127.0.0.1 8090
mitmweb --listen-port 8090 --web-port 8091 --allow-hosts '^api\.dblinter\.app'
[20:36:20.907] HTTP(S) proxy listening at *:8090.
[20:36:20.908] Web server listening at http://127.0.0.1:8091/?token=f83b02032aaaccd282ad3925a484fcdb

The mitmweb command starts the proxy and listens on port 8090 for TLS traffic between localhost and api.dblinter.app. All other traffic is bypassed.

The mitmweb proxy also opens the following web page:

mitmproxy after start up

Intercepting Traffic

To generate traffic, we launch VS Code and open a SQL file. This produces the following in the output panel for dbLinter:

2026-08-23 20:37:43.216 [Info ] Starting dbLinter Language Server.
2026-08-23 20:37:43.539 [Info ] connect.
2026-08-23 20:37:43.611 [Info ] initialize VSCode 1.10.0.
2026-08-23 20:37:43.646 [Info ] didOpen file:///.../dbl_client_types.sql.
2026-08-23 20:37:43.651 [Info ] AntlrCacheCoordinator initialized with parallel degree 1 and clearCacheThreshold 2048 of 16384 MB.
2026-08-23 20:37:43.671 [Warn ] TLS certificate and hostname verification are disabled for dbLinter repository API calls. Use this temporary workaround only when TLS interception cannot be bypassed.
2026-08-23 20:37:45.533 [Info ] Configuration dbLinter of tenant Grisselbav loaded with 294 check methods.
2026-08-23 20:37:45.534 [Info ] didChangeConfiguration.
2026-08-23 20:37:45.703 [Info ] tests returned 43 tests.
2026-08-23 20:37:45.796 [Info ] parseAndCheck file:///.../dbl_client_types.sql.
2026-08-23 20:37:45.910 [Info ] hasFeature Config returned true.
2026-08-23 20:37:46.286 [Info ] parseAndCheck completed in 0.489 sec including 0.052 sec for checks.
2026-08-23 20:37:46.289 [Info ] diagnostics for file:///.../dbl_client_types.sql with 2 issues.

The log contains a warning that TLS certificate and hostname verification are disabled.

dbLinter analyses SQL and APEXlang files locally. The captured traffic lets us verify what is sent to the dbLinter API. It contains the API key and session data, but not the contents of the analysed files. The source code therefore remains within the local network.

mitmproxy request message

It goes without saying that it is not good to expose the API key in plain text.

The proxy also shows the decrypted response:

mitmproxy response message

The session object in the response contains a signature. The client can therefore detect changes to the signed content, including the validators. This prevents the proxy from silently modifying the validators or injecting malicious code. However, the signature does not prevent the proxy from reading the request and response.

Enforce TLS Verification

Now let’s uncheck the Allow Insecure TLS checkbox and execute the Reload Window command.

disallow insecure TLS in VS Code

This produces the following in the output panel for dbLinter:

2026-08-23 20:52:37.281 [Info ] Starting dbLinter Language Server.
2026-08-23 20:52:37.550 [Info ] connect.
2026-08-23 20:52:37.606 [Info ] initialize VSCode 1.10.0.
2026-08-23 20:52:38.047 [Info ] didOpen file:///.../dbl_client_types.sql.
2026-08-23 20:52:38.049 [Info ] AntlrCacheCoordinator initialized with parallel degree 1 and clearCacheThreshold 2048 of 16384 MB.
2026-08-23 20:52:38.375 [Error] Failed to load configuration.

org.springframework.web.client.ResourceAccessException: I/O error on POST request for "https://api.dblinter.app/api/client-session/open": (certificate_unknown) PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

The proxy presented a certificate for api.dblinter.app which was not issued by a trusted certification authority.

The proxy console therefore shows the following log entry:

[20:52:38.217][127.0.0.1:60439] server connect api.dblinter.app:443 (91.98.90.2:443)
[20:52:38.360][127.0.0.1:60441] client connect
[20:52:38.375][127.0.0.1:60439] Client TLS handshake failed. The client does not trust the proxy's certificate for api.dblinter.app (OpenSSL Error([('SSL routines', '', 'ssl/tls alert certificate unknown')]))
[20:52:38.377][127.0.0.1:60439] client disconnect
[20:52:38.380][127.0.0.1:60439] server disconnect api.dblinter.app:443 (91.98.90.2:443)

The REST API call failed before the proxy received the HTTP request. Therefore, the API key and other request data were not exposed.

Reset Network Configuration and Uninstall Proxy

Let’s stop the proxy by pressing Ctrl-C in the terminal window running it. Then run the following:

networksetup -setsecurewebproxystate "Wi-Fi" off
brew uninstall mitmproxy
rm -rf ~/.mitmproxy

Conclusion

The Allow Insecure TLS option solves a practical problem in environments where TLS inspection cannot easily be bypassed. However, it disables certificate and hostname verification. A proxy or an attacker controlling the network can then read requests, including the API key.

The captured traffic also confirms that dbLinter analyses SQL and APEXlang files locally. Signed server responses protect the downloaded configuration from manipulation, but they do not protect confidential request data.

Therefore, enable this option only as a temporary workaround on a trusted network. The preferred solution is to configure a TLS inspection bypass. Disable the option again as soon as possible.

The post The Checkbox That Disables TLS appeared first on Philipp Salvisberg's Blog.

]]> 0 Philipp Salvisberg http://www.salvis.com/ <![CDATA[The Return of SQLcl’s SCRIPT Command]]> https://www.salvis.com/blog/?p=21049 2026-07-27T09:17:27Z 2026-07-25T14:02:15Z Introduction The script command was introduced with SQLcl 4.2. It is based on JSR 223, the Java Scripting API, and makes it possible to run JavaScript from SQLcl. This adds client-side control flow, file access, better control of host commands and access to Java classes and JavaScript libraries. JDK 8 was the […]

The post The Return of SQLcl’s SCRIPT Command appeared first on Philipp Salvisberg's Blog.

]]> Introduction

The script command was introduced with SQLcl 4.2. It is based on JSR 223, the Java Scripting API, and makes it possible to run JavaScript from SQLcl. This adds client-side control flow, file access, better control of host commands and access to Java classes and JavaScript libraries.

JDK 8 was the latest and greatest back in 2015 when Kris Rice promoted this feature on his blog. The script command worked out of the box because JDK 8 included the Nashorn JavaScript engine. Nashorn was deprecated in JDK 11 and removed in JDK 15, but continues as a standalone OpenJDK library for JDK 11 and newer. The current version 26.2 of SQLcl requires JDK 11 or newer, but does not include a JavaScript engine. Therefore, script no longer works with a modern standard JDK.

The documented solution is to use GraalVM and install its JavaScript engine using the command gu install js. However, gu has been removed from more recent GraalVM distributions. Applications requiring a JavaScript engine must therefore provide the necessary Maven dependencies themselves.

Furthermore, the SQL Developer extension for VS Code comes with its own JDK 25. We cannot simply replace it with an older GraalVM JDK since some components require a JDK 25 and are therefore incompatible with older JDK versions.

The script command does not work in SQLcl embedded in SQL Developer for VS Code.

Let’s change that.

Patching SQLcl in SQL Developer for VS Code

I experimented with various approaches. The result is sqlcl-js-patch.sh. The idea is to download the missing JavaScript engine and its dependencies from Maven Central and add them to an SQLcl installation. This shell script supports GraalJS and Nashorn on JDK 17 and newer.

For SQL Developer for VS Code, I prefer Nashorn. It is compatible with the behaviour we had with JDK 8 and JDK 11 and produces no warnings when SQLcl starts.

Close all SQLcl sessions in VS Code. Then run the following command in a macOS, Linux or Git Bash shell:

1) Patch SQLcl with Nashorn JavaScript engine
curl --fail --location --silent --show-error \
  https://raw.githubusercontent.com/PhilippSalvisberg/sqlcl-js-patch/refs/heads/main/sqlcl-js-patch.sh |
  sh -s -- add nashorn "sqlcl_home=$HOME/.vscode"
Downloading nashorn-core-15.7.jar
Downloading asm-7.3.1.jar
Downloading asm-commons-7.3.1.jar
Downloading asm-analysis-7.3.1.jar
Downloading asm-tree-7.3.1.jar
Downloading asm-util-7.3.1.jar
No matching libraries found in /Users/phs/.vscode/extensions/oracle.sql-developer-26.2.0-darwin-arm64/dbtools/sqlcl/lib.
Installed nashorn-core-15.7.jar
Installed asm-commons-7.3.1.jar
Installed asm-7.3.1.jar
Installed asm-analysis-7.3.1.jar
Installed asm-util-7.3.1.jar
Installed asm-tree-7.3.1.jar
No nashorn.args VM option found in macOS/Linux launcher; skipped Nashorn launcher patch.
Installed nashorn libraries in /Users/phs/.vscode/extensions/oracle.sql-developer-26.2.0-darwin-arm64/dbtools/sqlcl/lib.

The patch script locates the most recent Oracle SQL Developer extension in the $HOME/.vscode/extensions directory. It adds the necessary JAR files to the embedded SQLcl, whose directory structure differs from that of standalone SQLcl.

Now start a new SQLcl session in VS Code and run:

2) Test script command
script
print('Hello from Nashorn');
/
SQLcl: Release 26.2 Production on Sat Jul 25 13:19:46 2026

Copyright (c) 1982, 2026, Oracle.  All rights reserved.

Connected to:
Oracle AI Database 26ai Free Release 23.26.2.0.0 - Develop, Learn, and Run for Free
Version 23.26.2.0.0

Hello from Nashorn
SQL>

This does not work when the code is executed directly in a SQL Developer worksheet. It works when you select Run in SQLcl.

That’s it. The script command is back.

Please note that updating the SQL Developer extension installs a new embedded SQLcl. In that case, run the patch command again.

Does It Work With GraalJS?

Yes.

Just pass graaljs instead of nashorn:

3) Patch SQLcl with GraalJS JavaScript engine
curl --fail --location --silent --show-error \
  https://raw.githubusercontent.com/PhilippSalvisberg/sqlcl-js-patch/refs/heads/main/sqlcl-js-patch.sh |
  sh -s -- add graaljs "sqlcl_home=$HOME/.vscode"
Downloading collections-25.1.3.jar
Downloading icu4j-25.1.3.jar
Downloading jniutils-25.1.3.jar
Downloading js-language-25.1.3.jar
Downloading js-scriptengine-25.1.3.jar
Downloading nativeimage-25.1.3.jar
Downloading polyglot-25.1.3.jar
Downloading regex-25.1.3.jar
Downloading truffle-api-25.1.3.jar
Downloading truffle-compiler-25.1.3.jar
Downloading truffle-runtime-25.1.3.jar
Downloading word-25.1.3.jar
Downloading xz-25.1.3.jar
Deleted nashorn-core-15.7.jar
Deleted asm-commons-7.3.1.jar
Deleted asm-7.3.1.jar
Deleted asm-analysis-7.3.1.jar
Deleted asm-util-7.3.1.jar
Deleted asm-tree-7.3.1.jar
Deleted asm-commons-7.3.1.jar
Deleted asm-analysis-7.3.1.jar
Deleted asm-tree-7.3.1.jar
Deleted asm-util-7.3.1.jar
Installed collections-25.1.3.jar
Installed regex-25.1.3.jar
Installed truffle-compiler-25.1.3.jar
Installed polyglot-25.1.3.jar
Installed truffle-api-25.1.3.jar
Installed jniutils-25.1.3.jar
Installed truffle-runtime-25.1.3.jar
Installed js-language-25.1.3.jar
Installed xz-25.1.3.jar
Installed word-25.1.3.jar
Installed icu4j-25.1.3.jar
Installed js-scriptengine-25.1.3.jar
Installed nativeimage-25.1.3.jar
Installed graaljs libraries in /Users/phs/.vscode/extensions/oracle.sql-developer-26.2.0-darwin-arm64/dbtools/sqlcl/lib.

Let’s start a new SQLcl session in VS Code and run:

4) Test script command
script
print('Hello from GraalJS');
/
Show/hide output 
SQLcl: Release 26.2 Production on Sat Jul 25 12:20:22 2026

Copyright (c) 1982, 2026, Oracle.  All rights reserved.

WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::load has been called by com.oracle.truffle.polyglot.JDKSupport in module org.graalvm.truffle (file:/Users/phs/.vscode/extensions/oracle.sql-developer-26.2.0-darwin-arm64/dbtools/sqlcl/lib/truffle-api-25.1.3.jar)
WARNING: Use --enable-native-access=org.graalvm.truffle to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled

[To redirect Truffle log output to a file use one of the following options:
* '--log.file=<path>' if the option is passed using a guest language launcher.
* '-Dpolyglot.log.file=<path>' if the option is passed using the host Java launcher.
* Configure logging using the polyglot embedding API.]
[engine] WARNING: The polyglot engine uses a fallback runtime that does not support runtime compilation to native code.
Execution without runtime compilation will negatively impact the guest application performance.
The following cause was found: JVMCI is not enabled for this JVM. Enable JVMCI using -XX:+EnableJVMCI.
For more information see: https://www.graalvm.org/latest/reference-manual/embed-languages/#runtime-optimization-support.
To disable this warning use the '--engine.WarnInterpreterOnly=false' option or the '-Dpolyglot.engine.WarnInterpreterOnly=false' system property.
[To redirect Truffle log output to a file use one of the following options:
* '--log.file=<path>' if the option is passed using a guest language launcher.
* '-Dpolyglot.log.file=<path>' if the option is passed using the host Java launcher.
* Configure logging using the polyglot embedding API.]
[engine] WARNING: The polyglot engine uses a fallback runtime that does not support runtime compilation to native code.
Execution without runtime compilation will negatively impact the guest application performance.
The following cause was found: JVMCI is not enabled for this JVM. Enable JVMCI using -XX:+EnableJVMCI.
For more information see: https://www.graalvm.org/latest/reference-manual/embed-languages/#runtime-optimization-support.
To disable this warning use the '--engine.WarnInterpreterOnly=false' option or the '-Dpolyglot.engine.WarnInterpreterOnly=false' system property.
WARNING: A terminally deprecated method in sun.misc.Unsafe has been called
WARNING: sun.misc.Unsafe::objectFieldOffset has been called by com.oracle.truffle.api.strings.TStringUnsafe (file:/Users/phs/.vscode/extensions/oracle.sql-developer-26.2.0-darwin-arm64/dbtools/sqlcl/lib/truffle-api-25.1.3.jar)
WARNING: Please consider reporting this to the maintainers of class com.oracle.truffle.api.strings.TStringUnsafe
WARNING: sun.misc.Unsafe::objectFieldOffset will be removed in a future release
[To redirect Truffle log output to a file use one of the following options:
* '--log.file=<path>' if the option is passed using a guest language launcher.
* '-Dpolyglot.log.file=<path>' if the option is passed using the host Java launcher.
* Configure logging using the polyglot embedding API.]
[engine] WARNING: The polyglot engine uses a fallback runtime that does not support runtime compilation to native code.
Execution without runtime compilation will negatively impact the guest application performance.
The following cause was found: JVMCI is not enabled for this JVM. Enable JVMCI using -XX:+EnableJVMCI.
For more information see: https://www.graalvm.org/latest/reference-manual/embed-languages/#runtime-optimization-support.
To disable this warning use the '--engine.WarnInterpreterOnly=false' option or the '-Dpolyglot.engine.WarnInterpreterOnly=false' system property.
[To redirect Truffle log output to a file use one of the following options:
* '--log.file=<path>' if the option is passed using a guest language launcher.
* '-Dpolyglot.log.file=<path>' if the option is passed using the host Java launcher.
* Configure logging using the polyglot embedding API.]
[engine] WARNING: The polyglot engine uses a fallback runtime that does not support runtime compilation to native code.
Execution without runtime compilation will negatively impact the guest application performance.
The following cause was found: JVMCI is not enabled for this JVM. Enable JVMCI using -XX:+EnableJVMCI.
For more information see: https://www.graalvm.org/latest/reference-manual/embed-languages/#runtime-optimization-support.
To disable this warning use the '--engine.WarnInterpreterOnly=false' option or the '-Dpolyglot.engine.WarnInterpreterOnly=false' system property.
[To redirect Truffle log output to a file use one of the following options:
* '--log.file=<path>' if the option is passed using a guest language launcher.
* '-Dpolyglot.log.file=<path>' if the option is passed using the host Java launcher.
* Configure logging using the polyglot embedding API.]
[engine] WARNING: The polyglot engine uses a fallback runtime that does not support runtime compilation to native code.
Execution without runtime compilation will negatively impact the guest application performance.
The following cause was found: JVMCI is not enabled for this JVM. Enable JVMCI using -XX:+EnableJVMCI.
For more information see: https://www.graalvm.org/latest/reference-manual/embed-languages/#runtime-optimization-support.
To disable this warning use the '--engine.WarnInterpreterOnly=false' option or the '-Dpolyglot.engine.WarnInterpreterOnly=false' system property.
Connected to:
Oracle AI Database 26ai Free Release 23.26.2.0.0 - Develop, Learn, and Run for Free
Version 23.26.2.0.0

[To redirect Truffle log output to a file use one of the following options:
* '--log.file=<path>' if the option is passed using a guest language launcher.
* '-Dpolyglot.log.file=<path>' if the option is passed using the host Java launcher.
* Configure logging using the polyglot embedding API.]
[engine] WARNING: The polyglot engine uses a fallback runtime that does not support runtime compilation to native code.
Execution without runtime compilation will negatively impact the guest application performance.
The following cause was found: JVMCI is not enabled for this JVM. Enable JVMCI using -XX:+EnableJVMCI.
For more information see: https://www.graalvm.org/latest/reference-manual/embed-languages/#runtime-optimization-support.
To disable this warning use the '--engine.WarnInterpreterOnly=false' option or the '-Dpolyglot.engine.WarnInterpreterOnly=false' system property.
Hello from GraalJS
SQL>

After several warnings, the expected result appears at the end.

I explained the GraalJS-related warnings in my GitHub repository. The following environment setting will suppress most of the warnings. Where you define this variable depends on your operating system and shell. In any case, the environment variable must be visible before you start VS Code.

5) Non-breaking JDK_JAVA_OPTIONS to suppress warnings
export JDK_JAVA_OPTIONS="-Dpolyglot.engine.WarnInterpreterOnly=false -Dpolyglot.js.nashorn-compat=true"

If you are only using JDK 24 or newer on your system, you can disable all warnings as follows. However, be aware that any JDK version below 24 will no longer work, because the Java runtime stops with an error when passing unknown JVM arguments.

6) Breaking JDK_JAVA_OPTIONS to suppress warnings
export JDK_JAVA_OPTIONS="--illegal-native-access=allow --sun-misc-unsafe-memory-access=allow -Dpolyglot.engine.WarnInterpreterOnly=false -Dpolyglot.js.nashorn-compat=true"

Can I Also Use This for Standalone SQLcl?

Yes.

Pass the SQLcl installation directory instead of the VS Code configuration directory:

7) Patch standalone SQLcl with Nashorn JavaScript engine (macOS/Linux only)
curl --fail --location --silent --show-error \
  https://raw.githubusercontent.com/PhilippSalvisberg/sqlcl-js-patch/refs/heads/main/sqlcl-js-patch.sh |
  sh -s -- add nashorn "sqlcl_home=/path/to/sqlcl"

This works very well on macOS and Linux. Besides installing the Nashorn libraries, the patch removes the following option from the bin/sql launcher:

-Dnashorn.args=--no-deprecation-warning

The standalone Nashorn engine does not support this option. It throws an exception while the engine is initialised, and SQLcl consequently reports JavaScript engine not found.

On Windows, bin/sql.exe is a binary executable. The patch script cannot modify it. It can add the Nashorn libraries when run from Git Bash, but it cannot apply the necessary launcher workaround. Therefore, Nashorn does not work with standalone SQLcl on Windows. GraalJS does not need this launcher change and is therefore the only option supported by the patch script on Windows:

8) Patch standalone SQLcl with GraalJS JavaScript engine
curl --fail --location --silent --show-error \
  https://raw.githubusercontent.com/PhilippSalvisberg/sqlcl-js-patch/refs/heads/main/sqlcl-js-patch.sh |
  sh -s -- add graaljs "sqlcl_home=/path/to/sqlcl"

This raises an interesting question. SQL Developer for VS Code also includes a Windows bin/sql.exe that the patch script cannot modify. So why does Nashorn work there?

But Why Does Nashorn Work in Embedded SQLcl?

I mentioned before that the embedded SQLcl version has a different folder structure (there is no lib/ext folder for third-party libraries). But that’s not the only difference.

The launcher is also different. Neither bin/sql nor bin/sql.exe includes the -Dnashorn.args=--no-deprecation-warning JVM option.

As a result, the Nashorn JavaScript engine works in the embedded SQLcl version of SQL Developer for VS Code.

Outlook

I hope this helps you bring the SQLcl script command back to life in your environments, especially in SQL Developer for VS Code, where using another Java runtime is not a practical option.

However, I also hope that we will not have to run sqlcl-js-patch.sh for every new SQLcl or SQL Developer extension version until the end of time. The patch consists mainly of adding libraries that are available from Maven Central. It would be great if the Oracle SQL Developer team included these libraries in a future update and made the script command work out of the box again.

Updated on 2026-07-27, mentioned OpenJDK Nashorn in paragraph 2.

The post The Return of SQLcl’s SCRIPT Command appeared first on Philipp Salvisberg's Blog.

]]> 2