[Discussion] Increasing minimum supported JDK (and dropping support for JDK 11)

[cushon]

Error Prone will eventually drop support for running on JDK 11. This bug is intended to collect input from the community on the timing of that decision. There aren't immediate plans to do this, but there are also reason to look forward to using Java > 11 language features in the implementation.

Note that using a newer JDK version to run javac during the build doesn't prevent building code that is deployed to earlier versions, the compiler just has to be configured with --release (or -source/-target/-bootclasspath). For example, it's supported to use the JDK 17 javac and pass --release 8 to compile Java 8 code that is deployed to a JDK 8 runtime.

Questions:

• What would the next minimum supported version be? (I think a likely answer is 17, since it's the next LTS after 11.)

• If you're currently running Error Prone on JDK 11, do you have a timeline for upgrading to a newer version?

[Stephan202]

Great topic. Some n=1 feedback: all Picnic-internal code targets JDK 17. For Error Prone Support we kept the baseline at JDK 11, but that does impede the use of text blocks in unit tests which is a shame, because they would be a great quality of life improvement i.c.w. CompilationTestHelper and BugCheckerRefactoringTestHelper (PicnicSupermarket/error-prone-support#198). (Given Error Prone's reliance on JDK internals we do want to run the tests against all supported JDKs, so testing only on JDK 15+ doesn't seem appropriate.)

[RobertTheBlair]

Dropping JDK 11 in 2023 would be premature. Where I work, we have not migrated everything off of JDK 8 yet. Any place that has a large codebase to maintain, especially libraries that are still in use by JDK 8 / 11 applications, will have a long road ahead of them to get to 17.
Getting 95% of apps and libraries to 17 won't happen for us for 2+ years.

[cushon]

Thanks! That sort of input is why I opened the issue. When we eventually do start requiring JDK 17 to run Error Prone I don't want that to be too onerous. It'll still be possible to continue to use older versions of Error Prone to get compatibility with older JDK versions, but we also don't want to do that too soon and cause fragmentation.

One thing to note is that using JDK 17 to run javac during the build doesn't prevent building code that is deployed to JDK 8, the compiler just has to be configured with --release 8 (or -source/-target/-bootclasspath).

At Google we aren't using JDK 8 anymore, and are using the latest javac to build while still supporting deployments to JDK 11.

[RobertTheBlair]

True about older versions. As long as it is a major version update to require min jdk 17, should be clear what to expect.

[ksilz]

I think it's too early to drop support for Java 11. Even the upcoming version 3 of the Quarkus framework still has Java 11 as the baseline.

[alexec]

We use Java 11 extensively and would prefer support is retained until it is out of LTS (2026?).

[cushon]

We use Java 11 extensively and would prefer support is retained until it is out of LTS (2026?).

@alexec do you know if using a newer javac version and passing --release 11 to target Java 11 would be an option for you (there's a note about that in #3803 (comment))? Or is that not something you're likely to do?

[remal]

@cushon using --release doesn't prevent from using Java api of later versions. So, you also need to use --system. I wouldn't say it's convenient for Error Prone users

[alexec]

We have 1000s of applications on Java 11. It's not feasible to migrate them.

[cushon]

@cushon using --release doesn't prevent from using Java api of later versions. So, you also need to use --system. I wouldn't say it's convenient for Error Prone users

That is not accurate, --release configures the language level and APIs, passing just --release 11 is equivalent to passing -source 11 -target 11 --system <path to JDK 11>.

(There are some situations --release doesn't support, e.g. I think it still can't be used together with --add-exports=, so --system is necessary for compilations that rely on that.)

We have 1000s of applications on Java 11. It's not feasible to migrate them.

Understood, to be clear that is not what I was asking. It's possible to use a newer version of javac at compile-time and still use an older JDK version in production, javac has support for targeting old JDK versions. E.g.:

$JAVA_17_HOME/bin/javac --release 11 Foo.java
$JAVA_11_HOME/bin/java Foo

[remal]

@cushon have you tried it yourself? I have, and in my case it didn't work without --system. Which is logical, as javac don't know the path of JDK 11. And it doesn't search it.

[cpovirk]

@remal I'm guessing that you're thinking of (e.g.) -source 8, which has exactly the problem you are describing. --release 8 was introduced largely because of that problem, as discussed in the Motivation section of JEP 247.