SQL Developer JDK 8 support dropped: bundled-JDK build or shared system JDK for team installs?

Direct answer

For most teams seeking a simple, low‑maintenance rollout, the bundled‑JDK build is the preferred choice. It pins a tested JDK version with each SQL Developer release, eliminating version‑matching work and reducing support overhead. If you already maintain a centralized Java infrastructure and want to save disk space, the no‑JDK build can be used, but you must keep the system JDK exactly aligned with the version listed in the SQL Developer release notes.

Why the bundled‑JDK build is usually better

• Each installer includes a JDK that Oracle has verified with that SQL Developer version.
• No need to coordinate JDK upgrades across machines; the IDE will always start with the correct Java.
• Support incidents related to "wrong Java version" are virtually eliminated.

When the no‑JDK build makes sense

Choose this variant only if:

1. You have an existing, centrally managed JDK deployment that can be kept at the exact version required.
2. Disk usage per workstation is a concern (the bundled JDK adds ~150‑200 MB).
3. Your deployment process can reliably update the JDK before each SQL Developer upgrade.

Steps for a no‑JDK rollout

1. Check the release notes for the target SQL Developer version to confirm the required JDK (e.g., JDK 11 for 21.2.x, JDK 17 for 22.2.x and later).
2. Install that JDK on a shared location or via your standard Java provisioning tool.
3. Edit sqldeveloper.conf (located in the IDE’s bin directory) and add or modify the line:

   SetJavaHome <path-to-jdk>

   This overrides any JAVA_HOME or PATH discovery.
4. Launch SQL Developer and verify the Java version via Help → About → Version tab; it should match the configured JDK.
5. Run a quick sanity check: connect to one of your database editions, open a worksheet, and execute a simple query.

Handling JDK version drift when upgrading SQL Developer (no‑JDK)

Before installing the newer SQL Developer release:

1. Read the new release notes to see if the required JDK version changed.
2. If it changed, update the SetJavaHome entry in sqldeveloper.conf to point to the new JDK.
3. Optionally automate this with a deployment script that reads the required version from the release notes and rewrites the config file.
4. After the config update, launch the upgraded IDE and verify the Java version as described above.

Missing diagnostic detail that could change the recommendation

Do you already maintain a centrally managed JDK that meets the version required by your target SQL Developer release? If the answer is “no,” the bundled‑JDK build avoids the extra coordination work; if “yes,” the no‑JDK build may save disk space.