Since you are asking about strategy, mine has always been: 1. Use the lowest JDK version that still has a user base of over 10% or 2. Use the minimum JDK version that meets the requirements for what the code base targets.
For a long time I attempted to stick to using JDK 8 for 3.x but at some point it just became unworkable. Trying to get fully compliant JPMS modules while sticking with multi-release stuff what becoming impossible. That necessitated a move to Java 11, but we have no other features or dependencies that require a newer JDK version. https://newrelic.com/resources/report/2023-state-of-the-java-ecosystem shows the following usage stats: Java 8 - 33% Java 11 - 56% Java 17 - 9% Given those stats a switch to requiring Java 17 as the base version seems pretty premature. Ralph > On Jun 5, 2023, at 9:31 AM, Matt Sicker <m...@musigma.org> wrote: > > Piotr raised an interesting question recently which deserves a dedicated > thread here: what should our strategy be for supporting various versions of > Java? Our current strategy is essentially Java 8 for 2.x and Java 11 for 3.x, > but with projects like Spring pushing Java 17 as a base requirement and Java > 21 (the latest LTS release) coming out in September, we may want to devise a > version support strategy. > > As for relevant features in newer releases, we can rely on multi-version jars > to support specific APIs, but even some of the more relevant ones like scoped > values and string templates are still in preview mode as of version 21.
