SQLcl Archives - Philipp Salvisberg's Blog https://www.salvis.com/blog/tag/sqlcl/ Database-centric development Mon, 27 Jul 2026 09:17:27 +0000 en-US hourly 1 https://wordpress.org/?v=7.0.4 https://www.salvis.com/blog/wp-content/uploads/2014/04/favicon.png SQLcl Archives - Philipp Salvisberg's Blog https://www.salvis.com/blog/tag/sqlcl/ 32 32 The Return of SQLcl’s SCRIPT Command https://www.salvis.com/blog/2026/07/25/the-return-of-sqlcls-script-command/ https://www.salvis.com/blog/2026/07/25/the-return-of-sqlcls-script-command/#comments Sat, 25 Jul 2026 14:02:15 +0000 https://www.salvis.com/blog/?p=21049 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.

]]> https://www.salvis.com/blog/2026/07/25/the-return-of-sqlcls-script-command/feed/ 2 Installing MLE Modules in the Oracle Database https://www.salvis.com/blog/2023/11/26/installing-mle-modules-in-the-oracle-database/ Sun, 26 Nov 2023 17:56:09 +0000 https://www.salvis.com/blog/?p=12931 Introduction In my previous blog post, I’ve shown how you can deploy an npm module from a URL and a custom ESM module from a local file into a remote Oracle Database 23c using JavaScript and SQLcl. This works well. However, for two MLE modules, I had to write 22 lines of […]

The post Installing MLE Modules in the Oracle Database appeared first on Philipp Salvisberg's Blog.

]]> Introduction

In my previous blog post, I’ve shown how you can deploy an npm module from a URL and a custom ESM module from a local file into a remote Oracle Database 23c using JavaScript and SQLcl. This works well. However, for two MLE modules, I had to write 22 lines of code with duplications. I do not like that. I have therefore developed a small SQLcl custom command that greatly simplifies the installation of MLE modules in the Oracle Database.

Installing the mle Custom Command

Start SQLcl and run the following command to install the custom command mle in the current session.

script https://raw.githubusercontent.com/PhilippSalvisberg/mle-sqlcl/main/mle.js register

The SQLcl script command can read a JavaScript file from the local file system or from a URL. If you feel uncomfortable running JavaScript files directly from a URL, you can have a look at the GitHub repo first and download and run a chosen version of the script from the local file system.

The register subcommand registers the mle script as an SQLcl command. However, this registration is not permanent. It will be lost after closing SQLcl. To make the custom command available in every new SQLcl session add the command above to your login.sql or startup.sql. SQLcl executes these files on start-up or after establishing a new connection. Just make sure that you have configured the SQLPATH environment variable accordingly.

Providing Help

Now you can run the mle command like this:

mle

Without parameters, an error message is displayed along with information on how to use this command.

Output of mle command without parameters

Installing Validator

Now we know the syntax to install an MLE module from a URL. However, what’s the URL for an npm module? We use the free OpenSource CDN jsDelivr for that. They provide a service returning an npm module as an ECMAScript module. The result can be used in a browser and also in an Oracle Database. The URL looks like this:

https://esm.run/npm-package-name@npm-package-version

We want to install the current version 13.11.0 of the npm module validator. Based on the information provided above our SQLcl command for that looks like this:

mle install validator_mod https://esm.run/validator@13.11.0 13.11.0

And here is the result in SQLcl :

Output of successfully executed mle command to install the validator module from npm

Please note that the response message by SQLcl 23.3 is not 100% correct for MLE modules. However, our module is installed correctly. We verify that later.

Maybe you’d like to know what the SQL statement looks like to install this module. The last statement is still in SQLcl’s buffer. Therefore we can type l followed by enter to see the content of the buffer.


SQLcl's buffer

The first line contains the start of the SQL statement. Lines 2 to 7 are comments generated by jsDelivr. Line 8 contains the complete module. Yes, as a single line. The code is minified. All unnecessary whitespace is gone and internally used identifiers are shortened to save space. On line 9 we would see a JavaScript comment with a pointer to a map file that points to the original, nicely formatted source code. This is interesting when debugging in other environments. It’s currently not used in the database.

SQLcl buffer containing the SQL command to install the validator module


Querying MLE Modules

The following SQL statement shows some data regarding the previously deployed MLE module:

set sqlformat ansiconsole
select module_name, version, language_name, length(module)
  from user_mle_modules;

The result in SQLcl looks like this:

We see the version of the module and also the size in bytes of the blob column where the module is stored. It is one byte larger than the result of the URL since It contains a final line feed character due to the way we built the SQL statement.

IMO it is helpful to provide the version of the external ESM as long as there is no proper package registry within the Oracle Database.

Verifying Installation

Let’s write a call specification in order to verify the successful installation of the validator module.

create or replace function is_email(
   in_email in varchar2
) return boolean as mle module validator_mod signature 'default.isEmail(string)';
/

Now we can run the following query to verify e-mail addresses and the installation of the validator module:

select is_email('jane.doe@example.org') as jane_doe,
       is_email('john.doe@example') as john_doe;

In SQLcl 23.3 the result looks like this (boolean values as 1 and 0):

Result of calling the is_email validator function in SQLcl

And in SQL*Plus 23.3 the result looks like this (boolean values as TRUE and FALSE):

Result of calling the is_email validator function in SQL*Plus

Installing More Modules

Let’s install some other modules I find useful. You find them on npm if you want to know what they do.

mle install sentiment_mod https://esm.run/sentiment@5.0.2 5.0.22
mle install jimp_mod https://esm.run/jimp@0.22.10/browser/lib/jimp.js 0.22.10
mle install sql_assert_mod https://esm.run/sql-assert@1.0.3 1.0.3
mle install lodash_mod https://esm.run/lodash@4.17.21 4.17.21
mle install js_yaml_mod https://esm.run/js-yaml@4.1.0 4.1.0
mle install minimist_mod https://esm.run/minimist@1.2.8 1.2.8
mle install typeorm_mod https://esm.run/typeorm@0.3.17 0.3.17

Installing all modules is just a matter of a few seconds.

Conclusion

Using the SQLcl custom mle command to install ECMAScript modules from a file or from a URL is not only easy and fast, but it is also an excellent way to provide tested functionality within the database.

Technically it should be possible to generate the PL/SQL call specifications based on the information that is provided for IDEs to better support code completion (type definitions). I hope that Oracle will provide such a feature in one of the coming releases of SQLcl or as part of a dedicated MLE tool (similar to dbjs which was part of the experimental version of the MLE back in 2017). Even if I do not want to provide access to all underlying functionality of an MLE module within the database or provide the functionality with the same signature, a PL/SQL package with all call specifications would simplify the work for a wrapper PL/SQL package that exposes just the relevant subset in a suitable way for the use in PL/SQL or SQL.

The post Installing MLE Modules in the Oracle Database appeared first on Philipp Salvisberg's Blog.

]]> Patching SQL Developer 20.2 with SQLcl’s Formatter https://www.salvis.com/blog/2020/11/01/patching-sql-developer-20-2-with-sqlcls-formatter/ https://www.salvis.com/blog/2020/11/01/patching-sql-developer-20-2-with-sqlcls-formatter/#comments Sun, 01 Nov 2020 15:37:09 +0000 https://www.salvis.com/blog/?p=10802 Introduction SQLcl 20.3.0 was released on October 29, 2020. It’s the first time I remember that we have a SQLcl version without the corresponding SQL Developer version. This is a pity because this SQLcl version also contains formatter fixes. And formatting code is something I do more often in the full-blown IDE […]

The post Patching SQL Developer 20.2 with SQLcl’s Formatter appeared first on Philipp Salvisberg's Blog.

]]> Introduction

SQLcl 20.3.0 was released on October 29, 2020. It’s the first time I remember that we have a SQLcl version without the corresponding SQL Developer version. This is a pity because this SQLcl version also contains formatter fixes. And formatting code is something I do more often in the full-blown IDE than in the stripped-down command line interface. In this blog post, I show you how you can patch your SQL Developer installation and make the formatter fixes available there as well.

Disclaimer

What I do here is an experiment and most probably not really legal. It’s nothing I suggest you should do in your production environment. If you feel uneasy, don’t do it. What you do might destroy your SQL Developer installation.

Prerequisites

For this experiment you need

  • SQLcl 20.3.0
  • SQL Developer 20.2.0
  • JDK8 or JDK11

These software components are all installed on your computer. I do not explain in this blog post how to do it.

Solution Approach

SQLcl and SQL Developer provide a dbtools-common.jar file. This file contains the formatter (besides other things). We copy this file from the SQLcl installation to the SQL Developer installation.

That would be all if SQL Developer would load the Guava library before opening a connection. But it does not because it was not required for version 20.2 of dbtools-common.jar. Therefore we put the VersionTracker.class and the SetServerOutput.class (which do not use Guava) from the original SQL Developer installation into the dbtools-common.jar file.

Another option would be to embed the classes from the guava.jar.

Step by Step Instruction

Step 1 – Quit SQL Developer

We are going to patch SQL Developer. This is not possible on Windows if SQL Developer is running. On other OS this might have strange effects. Therefore quit SQL Developer.

Step 2 – Rename SQLDev’s dbtools-common.jar

Find the dbtools-common.jar in your SQL Developer installation. In my case the file is in this directory: /Applications/SQLDeveloper20.2.0.app/Contents/Resources/sqldeveloper/sqldeveloper/lib. Rename this file to dbtools-common.original.jar.

Rename SQLDev’s dbtools-common.jar
cd /Applications/SQLDeveloper20.2.0.app/Contents/Resources/sqldeveloper/sqldeveloper/lib
mv dbtools-common.jar dbtools-common.original.jar

Rename SQLDev’s dbtools-common.jar
cd C:\app\sqldeveloper20.2.0\sqldeveloper\lib
ren dbtools-common.jar dbtools-common.original.jar

Step 3 – Copy SQLcl’s dbtools-common.jar

Find the dbtools-common.jar in your SQLcl installation. In my case, the file is in this directory: /usr/local/bin/sqlcl/lib. Copy the file to the SQLDev’s directory (where the dbtools-common.original.jar is located).

Copy SQLcl’s dbtools-common.jar
cd /usr/local/bin/sqlcl/lib
cp dbtools-common.jar /Applications/SQLDeveloper20.2.0.app/Contents/Resources/sqldeveloper/sqldeveloper/lib

Copy SQLcl’s dbtools-common.jar
cd C:\app\sqlcl\lib
copy dbtools-common.jar C:\app\sqldeveloper20.2.0\sqldeveloper\lib

Step 4 – Patch dbtools-common.jar

Open a terminal window and change to the directory of the dbtools-common.original.jar file. Run there the following commands to create a patched version of dbtools-common.jar:

Patch dbtools-common.jar
cd /Applications/SQLDeveloper20.2.0.app/Contents/Resources/sqldeveloper/sqldeveloper/lib
jar -xvf dbtools-common.original.jar oracle/dbtools/db/VersionTracker.class
jar -xvf dbtools-common.original.jar oracle/dbtools/raptor/newscriptrunner/commands/SetServerOutput.class
jar -u0vMf dbtools-common.jar oracle/dbtools
rm -rf oracle

Patch dbtools-common.jar
cd C:\app\sqldeveloper20.2.0\sqldeveloper\lib
jar -xvf dbtools-common.original.jar oracle/dbtools/db/VersionTracker.class
jar -xvf dbtools-common.original.jar oracle/dbtools/raptor/newscriptrunner/commands/SetServerOutput.class
jar -u0vMf dbtools-common.jar oracle/dbtools
rmdir /s /q oracle

Here is some explanation:

  • First, we change to the directory where the files dbtools-common.original.jar (version 20.2.0) and dbtools-common.jar (version 20.3.0)  are stored. In your case, the directory name may differ.
  • On the second and third line, we extract the VersionTracker.class and the SetServerOutput.class from the dbtools-common.original.jar file. The classes are stored in a newly created directory oracle.
  • On the fourth line, we copy the previously extracted classes into the dbtools-common.jar file.
  • And on the last line, we remove the oracle directory and its subdirectories.

Formatter Improvements

An example is the best to show the difference between version 20.2 and 20.3. I use the default formatter settings with just one change. “No breaks” for “Line Breaks On Boolean connectors”.

And here are the results after formatting the code once.

There are two significant improvements to the formatter. Both are related to comment and whitespace handling and therefore are independent of an Arbori program.

  • The line of code after a comment is no longer indented additionally.
  • The line break after a single-line comment is no longer lost. As a result, the formatter will no longer comment out code.

While the first bug leads to badly formatted code, the second bug is really nasty. It breaks your code. This happens when you use single-line comments on consecutive lines. In most cases, this will lead to compile errors. However, I showed that the resulting code may be syntactically correct and a wrong formatting result could go unnoticed.

Updated on 2020-11-03, fixed typo in jar file names (db-common... to dbtools-common...).

Updated on 2020-11-05, added SetServerOutput.class to the patched jar file. Otherwise, no SQL can be processed in a worksheet. Mentioned an alternative option to embed the classes from the guava.jar. Renamed chapter “Overview” to “Solution Approach”.

The post Patching SQL Developer 20.2 with SQLcl’s Formatter appeared first on Philipp Salvisberg's Blog.

]]> https://www.salvis.com/blog/2020/11/01/patching-sql-developer-20-2-with-sqlcls-formatter/feed/ 1