Install SQL Developer in Oracle Linux

[root@grid ~]# rpm -Uhv /home/oracle/jdk-17.0.12_linux-x64_bin.rpm
warning: /home/oracle/jdk-17.0.12_linux-x64_bin.rpm: Header V3 RSA/SHA256 Signature, key ID ad986da3: NOKEY
Preparing...                          ################################# [100%]
Updating / installing...
   1:jdk-17-2000:17.0.12-8            ################################# [100%]

The NOKEY warning is harmless — it just means the Oracle public key isn't in RPM's local keyring. The package installs cleanly.

To confirm where it landed:

[root@grid ~]# ls -d /usr/java/jdk-17*
/usr/java/jdk-17  /usr/java/jdk-17-oracle-x64

Two entries showed up: /usr/java/jdk-17 is a convenience symlink, and /usr/java/jdk-17-oracle-x64 is the actual installation directory. I made a mental note to use the canonical path when configuring SQL Developer — symlinks can drift if more JDKs get installed later.

A sanity check that JDK 17 itself worked, run as the grid user this time:

[grid@grid ~]$ /usr/java/jdk-17-oracle-x64/bin/java --version
java 17.0.12 2024-07-16 LTS
Java(TM) SE Runtime Environment (build 17.0.12+8-LTS-286)
Java HotSpot(TM) 64-Bit Server VM (build 17.0.12+8-LTS-286, mixed mode, sharing)

Clean install. Now the trick was to make SQL Developer use this JDK instead of JDK 26.

This is the part that surprises people who haven't dealt with multi-JDK Linux hosts before. The system java command is controlled by alternatives, and the most recently installed JDK usually wins the link. After installing JDK 17 after JDK 26, my system default was still JDK 26 — and SQL Developer's launcher script just calls java, picking up whatever is first on the PATH.

You can chase this by reconfiguring alternatives, but that changes the system-wide default for every Java application on the host — Oracle Enterprise Manager, custom scripts, anything else relying on java. That's a heavy hammer for what is really a per-application problem.

The clean answer is to tell SQL Developer specifically which JDK to launch with, leaving the system default alone. SQL Developer reads two configuration files at startup:

1. product.conf — the per-user config, under ~/.sqldeveloper/<version>/product.conf. This is where SQL Developer stores the user's chosen JDK after the first-run prompt.
2. sqldeveloper.conf — the install-level config, under <install_dir>/sqldeveloper/bin/sqldeveloper.conf. This is the global fallback.

The directive that matters in both is SetJavaHome.

[root@grid ~]# ls ~/.sqldeveloper/
24.3.1

It had — 24.3.1 matched my installed version. The file existed:

[root@grid ~]# ls ~/.sqldeveloper/24.3.1/product.conf
/root/.sqldeveloper/24.3.1/product.conf

I edited it with vi and added one line:

SetJavaHome /usr/java/jdk-17-oracle-x64

That's the entire change. No quotes, no trailing slash, no JAVA_HOME= syntax — SQL Developer's config language uses SetJavaHome as the directive name and the bare path as the value.

[root@grid ~]# find / -name "sqldeveloper.conf" 2>/dev/null
/opt/sqldeveloper/sqldeveloper/bin/sqldeveloper.conf

So the SQL Developer install lives under /opt/sqldeveloper/. I edited the install-level config:

[root@grid ~]# vi /opt/sqldeveloper/sqldeveloper/bin/sqldeveloper.conf

And added the same directive:

SetJavaHome /usr/java/jdk-17-oracle-x64

The per-user product.conf takes precedence, but having the install-level config set means a fresh user account on this host gets a working SQL Developer out of the box without needing to chase down the same fix.

A Few Side Notes That Are Worth Internalizing

Don't run SQL Developer as root. I was logged in as root for the install steps because RPM installation requires it, but launching SQL Developer itself should happen as the oracle user (or a dedicated user). Connection profiles, TNS_ADMIN, wallet locations, and SSH key resolution are all sensitive to the user identity. Running it as root on a lab host is harmless; doing it on anything shared with production tooling will eventually surprise you.

The system default JDK is still 26. That's fine — JDK 26 is current and will be useful for anything modern that I might run on this host. SQL Developer is just one application that needs a specific older JDK, and SetJavaHome is the right scoped solution.

Why JDK 17 specifically? SQL Developer 24.x was released in 2024 and ships against JDK 17 LTS. Oracle's own release notes call this out, and the bundled JavaFX is the version that pairs with JDK 17. Trying to run it on 18+ works inconsistently, and on 21+ the module-system mismatches start showing up. JDK 17 is the safe target — it's also LTS, so it'll be supported for the practical lifetime of SQL Developer 24.x.

The jdk.jsobject error is a pattern, not a one-off. Any Java application that bundles JavaFX (especially its WebView component) will hit this same class of error on newer JDKs. NetBeans 12, JDeveloper 12c, and several other Oracle tools have versions that exhibit it. The same SetJavaHome-style fix applies in nearly every case — just point the launcher at the JDK the application was certified for.

Verification

After saving both config files, I relaunched SQL Developer. The boot-layer error was gone, the splash screen came up, and the workbench opened normally. From this point on, the per-user product.conf will keep my SQL Developer pinned to JDK 17 even if I install newer JDKs later, and the install-level config protects any new user on the host from the same issue.

Takeaways

1. Java application breakage on a modernized host is almost always a JDK version mismatch, not a corrupted install.
2. Read the error literally — jdk.jsobject not found, required by javafx.web directly tells you which subsystem is unhappy and points at the JDK module layer.
3. SetJavaHome in product.conf (or sqldeveloper.conf) is the right tool for pinning SQL Developer's runtime — don't fight the system-wide alternatives configuration for an application-specific problem.
4. On multi-JDK Linux hosts, always use the canonical install path (/usr/java/jdk-17-oracle-x64) rather than convenience symlinks (/usr/java/jdk-17). Symlinks can quietly repoint when packages get installed or upgraded.
5. Maintain both per-user and install-level configs when other users will share the host — it's a five-second copy and saves them hours later.