Consider a 1.28.1 release backporting --max-line-length for JDK 17 users #1495

Activity

1. xzxiaoshan commented on Oct 23, 2026

   

   xzxiaoshan

   on Oct 23, 2026

   Author

   More actions

   @cushon I don't know what the author thinks about this. Is it possible to consider it?
2. cushon commented on Oct 31, 2026

   

   cushon

   on Oct 31, 2026

   Collaborator

   More actions

   @xzxiaoshan Which build / IDE integrations are you using?

   This matters most for in-process integrations — Spotless (Maven/Gradle), fmt-maven-plugin, IDE plugins — which run the formatter on the project's own JDK. For those users there is no way to get --max-line-length without moving the entire build to JDK 21.

   Targeting JDK 17 doesn't require running the build tool on JDK 17.

   • In Maven, you can run maven on JDK 21+ (so plugins like spotless-maven-plugin and fmt-maven-plugin run on JDK 21+) while targeting JDK 17 for your project using either <maven.compiler.release>17</maven.compiler.release> or Maven Toolchains .
   • In Gradle, you can run the Gradle daemon on JDK 21+ so Spotless runs on JDK 21+, while configuring a JDK 17 Java Toolchain.
   • For IDE plugins, recent versions of IntelliJ and Eclipse already run the IDE and its plugins on a bundled JDK 21+ runtime regardless of the project's configured SDK or language level.

   Would running your build tool on JDK 21+ while targeting JDK 17 via --release or toolchains work for you?
3. xzxiaoshan commented on Oct 31, 2026

   

   xzxiaoshan

   on Oct 31, 2026

   Author

   More actions

   Thanks @cushon for the detailed reply.

   To answer your question: I'm one of the maintainers of agentscope-java, and we use Maven with spotless-maven-plugin's googleJavaFormat integration (AOSP style). The whole build — local development and CI, including the Spotless check — runs on JDK 17, matching our maven.compiler.source/target of 17.

   You're right that targeting JDK 17 doesn't require running the build tool on JDK 17; --release or toolchains would work technically. Our hesitation is about the cost this puts on every contributor, not about feasibility — and this cost does not land on CI, it lands on local machines:

   • CI is only a mirror of what every contributor runs locally. People execute mvn on their own machines all day long — build, test, spotless:apply before a commit — and today that works with a single JDK and a single JAVA_HOME pointing at 17. Moving the build tool to JDK 21 means every one of those local setups has to install a second JDK and keep the switching straight; otherwise ordinary daily commands start failing. IDE runners that default to the project JDK add the same reconfiguration on yet another layer.
   • We deliberately keep the development environment and the compile target identical (JDK 17), so a contributor needs exactly one JDK to build, format and test the project. It's the lowest-friction setup we can offer the community, and I believe many projects make the same choice.
   • Most of our contributors are JDK 17 users in their daily work: a large share of enterprise projects still require JDK 17 (it's the Spring Boot 3.x baseline), so their own projects are on JDK 17 as well. Switching between two JDKs every day — JDK 21 to build and format this framework, JDK 17 for everything else — is a visible and recurring burden, for what should be a trivial formatting concern.

   That said, --max-line-length is exactly the kind of feature worth asking about: it closes #425, one of the oldest and most-upvoted requests in this repo (~7 years), while being a tiny change with outsized value for downstream users. So let me renew the ask: would you consider a one-off 1.28.1 that cherry-picks just this feature onto v1.28.0? Such single-purpose backport releases are common practice in open-source projects, and it would let the entire JDK 17 ecosystem adopt the flag immediately — Spotless users can pin it directly via <googleJavaFormat><version>1.28.1</version> with no JDK changes, locally and in CI alike.

   The community remains happy to prepare and test the backport PR so the maintainer cost stays minimal. And if the answer is still no, we understand — thank you again for landing the feature itself and for taking the time to consider this.
4. tbroyer commented on Oct 31, 2026

   

   tbroyer

   on Oct 31, 2026

   Contributor

   More actions

   JDK 17's EOL is approaching (already the case for Oracle JDK since September): https://www.herodevs.com/blog-posts/java-8-11-17-eol-dates-by-openjdk-vendor-temurin-to-red-hat
   So maybe it's time to require JDK 21 (at least) for building your project? (using maven.compiler.release to continue targeting Java 17)
5. xzxiaoshan commented on Oct 31, 2026

   

   xzxiaoshan

   on Oct 31, 2026

   Author

   More actions

   @tbroyer
   Thanks — yes, we're well aware of the JDK support timelines, and I don't dispute them at all. It's just that in enterprise Java, the installed base moves much more slowly than the EOL table:

   • In fact, the same table you linked shows that most of the vendors people actually run in production continue to support JDK 17 well beyond Oracle's date — so for a large part of the real world, JDK 17 is still a supported platform today, not a legacy one.
   • Industry adoption surveys keep showing a very large share of production running on JDK 17 — and Java 8 is still alive and well, which says a lot about how long enterprise JDK generations persist in the real world. Supporting the JDK that enterprise projects actually run is a deliberate, pragmatic choice for us as a framework, not an oversight.

   And to be clear, we're not asking gjf to support JDK 17 forever — the mainline requiring JDK 21+ is entirely reasonable, and it's where we'll end up too once our user base moves. The ask is only about this transition window: a one-off 1.28.1 carrying just --max-line-length is a small, one-time cost on your side that would serve the very large population of JDK 17 builds for years, and the community remains happy to prepare and test the PR so the burden stays minimal.

   Either way, thank you both for engaging with this seriously — the willingness to discuss it is genuinely appreciated.