DBMS Output capture in SQL Developer under the JDK 17 minimum runtime

Question

Recent SQL Developer releases list JDK 17 as the minimum runtime, moving worksheet behavior onto a newer Java baseline than earlier installations targeted. The DBMS Output pane is one place that boundary shows: it polls a session's DBMS_OUTPUT buffer, and whether it uses repeated GET_LINE calls or a GET_ARRAY batch affects when lines appear and how much of the buffer is drained per poll.
What stays unclear is whether the capture behavior changed because of the JDK baseline, because of a SQL Developer release, or because of the JDBC driver in use. Extension loading adds another variable: extensions built against JDK 8 APIs may not load without a compatibility mode, and a disabled extension could change what the worksheet displays.
Confirm the release and runtime in Help > About, and compare the Java Runtime field with java -version on the machine that launches the tool. A worksheet running DBMS_OUTPUT.PUT_LINE inside a PL/SQL block gives a simple reference point.

Is the DBMS Output polling change tied to the JDK 17 minimum, or to the SQL Developer release that introduced it?
Does the behavior differ between a worksheet connection and one using a different JDBC driver?
Which installations in a mixed-JDK estate can keep the older capture behavior?

Tasadduq Burney · Answer

Answer to the core question
1. The change in DBMS Output polling is introduced by SQL Developer 22.2 (and later). It is a code‑level change that replaces the old line‑by‑line GET_LINE loop with a batch GET_ARRAY fetch. The JDK 17 minimum runtime is simply a prerequisite; the JDK itself does not alter the polling logic.
2. The polling method is driven by the JDBC driver in use. Oracle JDBC 21c and newer expose a GET_ARRAY API that SQL Developer exploits, so you see the new, faster batch behavior. Older drivers such as ojdbc19 do not support GET_ARRAY and SQL Developer falls back to the legacy GET_LINE loop, preserving the older timing.
3. In a mixed‑JDK estate, the only way to keep the legacy capture timing is to use an older JDBC driver (e.g., ojdbc19.jar) with the newer SQL Developer, or to adjust the DBMS Output buffer‑size preference to a very small value so that lines appear immediately. Switching the JDK alone will not change the behavior.
Confirmed facts

SQL Developer 22.2+ implements GET_ARRAY polling.
JDK 17 is a minimum requirement, not a cause of the change.
JDBC driver version determines whether GET_ARRAY is available.
DBMS Output buffer size in Preferences > Database > Output can influence line appearance timing.

Practical steps for verification

Open Help > About in SQL Developer. Note the SQL Developer version and the Java Runtime path.
In the worksheet, run a PL/SQL block that calls DBMS_OUTPUT.PUT_LINE 10 times. Observe the timestamps of each line in the DBMS Output pane.
Check the JDBC driver used for the connection:

Right‑click the connection in Connections pane, choose Properties, and look at the Driver entry.
Note the jar file name (e.g., ojdbc8.jar, ojdbc19.jar, ojdbc21.jar).

If you want legacy behaviour with a newer SQL Developer, replace the driver jar with an older version (e.g., ojdbc19.jar) and restart SQL Developer.
Optionally, adjust Preferences > Database > Output and set a very small Buffer size to force immediate line display.

What you need to confirm next
To give a precise recommendation for your environment, please tell us which JDBC driver is currently configured for the worksheet connection you are using.

DBMS Output capture in SQL Developer under the JDK 17 minimum runtime

1 answer

Answer to the core question

Confirmed facts

Practical steps for verification

What you need to confirm next

Your perspective belongs here.

0 question comments