Hey Ismaël, Thanks for bringing this up! The relevant thread you're looking for is over a year old: https://lists.apache.org/thread/cblz22jgllyvw2t63xs3fbzxcvhy5y42
Here was discussed to bump Parquet to a later version of Java, but we took Java 11 as an inbetween step to avoid taking big bumps. I would be in favor of moving 1.18.x to JDK17 for the reasons you mentioned. Kind regards, Fokko On 2026/05/23 10:03:11 Ismaël Mejía wrote: > Hi everyone, > > I would like to propose raising the minimum Java version for Apache > Parquet Java from 11 to 17. Java 17 is the current baseline LTS > version and has been out since September 2021 -- nearly four years. > > The broader ecosystem has already converged on Java 17 as the > minimum: > - Apache Spark 4.x requires Java 17 (dropped Java 8/11). > - Apache Flink 2.x uses Java 17 by default and recommends it as the > version to run on. > - Apache Hadoop 3.5+ requires JDK 17 on the server side. > - Apache Hive 4.2 requires JDK 21 as the minimum. > > As a library consumed by all of the above, Parquet Java staying on > Java 11 provides diminishing returns while imposing real costs: > 1. Build tooling compatibility. We already hit issues where the > Spotless formatter and Hadoop itself break on newer JDKs due to > removed APIs (Subject.getSubject() in JDK 23+, internal javac > methods in JDK 25). Staying on Java 11 as the baseline makes it > harder to test and support the JDK versions our consumers > actually run on. > 2. Language and API improvements. Java 17 brings records, sealed > classes, text blocks, pattern matching for instanceof, etc. These > improve code readability and reduce boilerplate. > 3. Performance. The JVM has had significant improvements in GC > (ZGC, Shenandoah), JIT compilation, and memory layout between > Java 11 and 17. Libraries compiled against a Java 17 baseline can > take advantage of these without workarounds. > 4. Security. Java 11 no longer receives public security > updates. Requiring 17 aligns with the security posture expected > of a widely deployed data format library. > > The first commit on the PR [1] already enforces Java 17 via the Maven > enforcer plugin and removes pre-17 workarounds (reflection hacks for > DirectByteBuffer cleanup, etc.). The full build passes on JDK 17, 21, > and 25. > > I don't expect this to be controversial given where the ecosystem is, > but wanted to give the community a chance to discuss before we merge. > > Thoughts? > [1] https://github.com/apache/parquet-java/pull/3579 > > Best, > Ismael > > P.S. My excuses if this has already been discussed. I could not find a > related issue / thread. >
