COPY INTO with PARQUET / DELTA_LAKE / remote schemes fails on JDK 23+ ('getSubject') — local JSON fixed in 0.20.3

[fupelaqu]

✅ Partly fixed in 0.20.3 — this issue is now NARROWED to the Hadoop-bound sources

Fixed (PR #188, merged 2026-08-03): COPY INTO from a local JSON / JSON_ARRAY file, and
local automatic format detection. These now read through java.nio.file and never touch Hadoop, so
they work on every JDK — 23, 24 and 25 included. Both the schemeless form
(/data/customers.jsonl) and the file: form (file:///data/customers.jsonl) are covered, as are
paths containing spaces and percent-encoded file: URIs.

Still broken, and what this issue now tracks:

COPY INTO source	JDK 8 – 22	JDK 23	JDK 24+
local JSON / JSON_ARRAY, schemeless or file:	✔	✔	✔ (fixed)
local file with auto-detected format	✔	✔	✔ (fixed)
local PARQUET	✔	✖ *	✖
local DELTA_LAKE	✔	✖ *	✖
any remote scheme (s3a://, s3://, gs://, abfs*://, wasb*://, hdfs://)	✔	✖ *	✖

* works on JDK 23 only if the host process is started with -Djava.security.manager=allow.

These remain Hadoop-bound by necessity: AvroParquetReader / ParquetFileReader consume a Hadoop
InputFile, Delta Standalone's DeltaLog.forTable takes a Hadoop Configuration, and for remote
schemes Hadoop is the filesystem layer (it also resolves the credentials). Closing this needs an
upstream Hadoop release that stops calling Subject.getSubject — upgrading to the currently
pinned hadoop-common 3.4.2 does not help; its UserGroupInformation.getCurrentUser() still takes
that path (bytecode-verified).

Workaround for the unsupported combinations is unchanged: run the host process on JDK 21 (or any
JDK ≤ 22); on JDK 23 you may instead pass -Djava.security.manager=allow. On JDK 24+ no flag helps.
See the DBeaver -vm recipe at the bottom of this issue.

Two corrections to the original report below

1. The boundary is JDK 23, not 24. JDK 23 already throws by default (java.security.manager
   unset or disallow) with a different message —
   getSubject is supported only if a security manager is allowed — and there
   -Djava.security.manager=allow still rescues it. JEP 486 (JDK 24) made it unconditional and
   removed the escape hatch. Any log-grep or error matcher must key on getSubject, never on the
   full is not supported string, or it silently misses JDK 23.
2. There were seven Hadoop entry points on the local JSON path, not five. The table below omits
   FileSource.validateFile — which runs before every read — and FileFormatDetector.isDeltaTable.
   A fix that patched only the five listed would still have thrown on JDK 23+.

Documented in DML statements → COPY INTO → JVM compatibility
and in known_limitations.md. Reducing the Hadoop footprint for JSON-only deployments is tracked
separately in #187.

---

_{Original report follows, unedited. Note the two corrections above: it says "JDK 24+" where
the true boundary is 23, and it lists five call sites where there were seven.}

COPY INTO <table> FROM '<local file>' fails on JDK 24 and newer with:

java.sql.SQLException: getSubject is not supported
	at app.softnetwork.elastic.jdbc.ElasticStatement.handleFailure(ElasticStatement.scala:139)
	at app.softnetwork.elastic.jdbc.ElasticStatement.execute(ElasticStatement.scala:379)

Reported from DBeaver 26.1.3, which since its 2026-07-19 build bundles Temurin 25.0.3. Nothing in
the driver changed — the host JVM did. Any tool or launcher on JDK 24+ is affected.

Root cause

Local file reads are routed through Hadoop even when the path is an ordinary local file:

// core/.../client/file/package.scala:338  (JsonFileSource.fromFile)
val is: InputStream = HadoopInputFile.fromPath(new Path(filePath), conf).newStream()

HadoopInputFile → FileSystem.get → UserGroupInformation.getCurrentUser() →
javax.security.auth.Subject.getSubject(AccessControlContext).

JEP 486 (JDK 24) permanently disabled the Security Manager, so Subject.getSubject now throws
UnsupportedOperationException("getSubject is not supported") unconditionally. The pre-24 escape
hatch is gone too: -Djava.security.manager=allow makes the VM refuse to start on 25
("Error occurred during initialization of VM").

Verified reproduction

Published artifact softclient4es8-jdbc-driver-0.2.3.jar, same probe calling FileSystem.get and
HadoopInputFile...newStream():

JVM	Result
Temurin 25.0.3 (DBeaver's bundled JRE)	FileSystem.get FAILED -> UnsupportedOperationException: getSubject is not supported
Temurin 25.0.3 + -Djava.security.manager=allow	VM fails to start
Zulu 21.0.3	FileSystem.get OK -> org.apache.hadoop.fs.LocalFileSystem, file opens

Impact

Shared core code, so every downstream artifact on all four ES lines is affected: JDBC driver, ADBC,
Arrow Flight SQL and the CLI/REPL — whenever the host JVM is 24+.

Source	Hadoop call sites	Needs Hadoop?
JsonFileSource (NDJSON / JSON Lines)	package.scala:338	No — only wants an InputStream
JsonArrayFileSource	package.scala:438,547,581	No — same
FileFormatDetector	package.scala:1121	No — sniffs the first bytes
ParquetFileSource	package.scala:223,289	Yes — AvroParquetReader / ParquetFileReader
DeltaFileSource	DeltaLog.forTable(conf, path)	Yes

Proposed fix

Add a local-path fast path — for a schemeless or file: path use Files.newInputStream and never
touch Hadoop — and use it at the five non-Parquet call sites above. That restores COPY INTO for
JSON/NDJSON/JSON-array on JDK 24+, and removes Hadoop from the hot path for the common case.

Parquet and Delta stay Hadoop-bound and therefore stay broken on JDK 24+ until Hadoop ships a fix
(HADOOP-19212 and friends); that is a separate dependency decision and should not block this one.

Worth noting as a side benefit: the driver fat jar is ~314 MB today, largely Hadoop + Parquet.

Workaround for users

Run the host tool on JDK 21. For DBeaver, in dbeaver.ini:

-vm
/path/to/jdk-21/Contents/Home/lib/libjli.dylib

(-vm must appear before -vmargs; a DBeaver update overwrites the file.)

Not this issue

A separate report of FileNotFoundException: ... (Operation not permitted) from the REPL on macOS is
not related: that is a TCC privacy denial on ~/Downloads for the hosting terminal app. The same
file opens fine from a process that has the grant, and a plain FileInputStream would fail
identically. No code change would address it.

[fupelaqu]

Partly fixed in 0.20.3 — #188 (merged 0385b991). Retitled and narrowed rather than closed.

COPY INTO from a local JSON / JSON_ARRAY file, and local format auto-detection, now work on every JDK including 23/24/25 — those paths read through java.nio.file and never call into Hadoop. Schemeless and file: forms, paths with spaces, and percent-encoded file: URIs are all covered. (The percent-encoded form — what java.io.File.toURI() emits — actually never worked on any JDK, because Hadoop re-encoded the %; it works now.)

This issue stays open for the sources that genuinely need Hadoop: local PARQUET, local DELTA_LAKE, and every remote scheme (s3a://, s3://, gs://, abfs*://, wasb*://, hdfs://). Closing it needs an upstream Hadoop that stops calling Subject.getSubject — bumping to the pinned hadoop-common 3.4.2 does not help, its UserGroupInformation.getCurrentUser() still takes that path.

Two corrections worth flagging for anyone matching on this in logs or dashboards:

1. The boundary is JDK 23, not 24. 23 already throws by default, with a different message: getSubject is supported only if a security manager is allowed. Match on getSubject, not on the full is not supported string, or you will miss every JDK 23 host. -Djava.security.manager=allow still rescues 23; nothing rescues 24+.
2. There were seven Hadoop entry points on the local JSON path, not the five listed originally — FileSource.validateFile (which runs before every read) and FileFormatDetector.isDeltaTable were missing. A five-site fix would still have thrown.

Workaround for the still-broken sources is unchanged: run the host process on JDK 21, or on 23 add -Djava.security.manager=allow. The DBeaver -vm recipe is at the bottom of the issue body.

Support matrix is published in dml_statements.md, known_limitations.md, and the docs site. Shrinking the Hadoop footprint for JSON-only deployments is #187.