andrey-borisov-patrianna commented on issue #56939: URL: https://github.com/apache/spark/issues/56939#issuecomment-4863004822
Agreed — I think the right move is to reconsider Spark's dependency on the now-removed `jdk.internal.ref.Cleaner` rather than work around it, and to get this into the 4.2 line rather than defer it. ## JDK 26 is a stable, GA release — not an early-access build JDK 26 reached general availability in March 2026 as a production-ready feature release under the standard six-month cadence. This isn't a preview or EA JDK we're testing speculatively; it's a shipping release that users are already adopting, so the `jdk.internal.ref.Cleaner` removal is a hard break against a supported runtime, not a moving target. ## Spark 4.2 is still in preview — this is the ideal window Because `4.2.0` hasn't gone GA yet, addressing this now means JDK 26 support lands cleanly in the first stable 4.2 release rather than requiring a follow-up patch. Preview is exactly the phase where new-JDK compatibility issues are meant to be caught and resolved. ## Why JVM flags won't cut it Since `jdk.internal.ref.Cleaner` is a **hard removal** in JDK 26 (not just an access restriction), `--add-opens` / `--add-exports` can't bring it back. The static initializer in `Platform.<clinit>` resolves the class via `Class.forName(...)` and rethrows the `ClassNotFoundException` as an `ExceptionInInitializerError`, so any code path that touches `Platform` fails immediately on JDK 26. ## Proper solution I'd lean toward migrating off the internal API entirely — falling back to the public `java.lang.ref.Cleaner` (available since JDK 9), or dropping the internal-cleaner path where it's no longer needed. That keeps Spark aligned with supported JDK APIs going forward instead of chasing each internal-class removal. ## Feature flag as a bridge If a full migration is too large for the 4.2 timeline, a feature flag (or graceful degradation) that lets `Platform` initialize without the internal `Cleaner` when it can't be resolved would at least unblock JDK 26 users, with the cleaner solution landing afterward. Since 4.2 is still in preview, this feels like the right window to decide on the direction. Happy to help test either approach against OpenJDK 26.0.1. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
