Set JDK21 as the baseline for the 3.0 major version

[andrross]

Issues Resolved

Resolves #153

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[andrross]

@reta Should we keep source compatibility at Java 11 so that we don't introduce syntax that can't be backported to 2.x? I'm thinking we should probably keep this constraint until we've got a release date for 3.0 and can make a clean break away from the 2.x line.

[reta]

@reta Should we keep source compatibility at Java 11 so that we don't introduce syntax that can't be backported to 2.x?

@andrross here is the thing, Apache Lucene 10 is using JDK-21 release (source + target), so we won't be able to stick to JDK-11 and use Apache Lucene 10 types (in general)

[andrross]

So the risk is that Lucene exposes something in its API that is only available in JDK 21+? How does that fail if we have a lower source constraint? Does it only fail if we attempt to use that thing?

[reta]

So the risk is that Lucene exposes something in its API that is only available in JDK 21+?

Correct, fe records.

How does that fail if we have a lower source constraint? Does it only fail if we attempt to use that thing?

I think it won't fail (since most of the construct are retrofitted into existing bytecode), but it will force to use weird combination (fe classes and records) to essentially describe the same things. Plus we are loosing a lot from language enhancements .