IMO the desired case is that I can use Java 11 to build and you can use Java 17. Unless I am forced to do otherwise I will always use the target version for the release build. For example, I wouldn’t want the changeling support to require Java 17 as then I would be unable to migrate Flume to use it.
Ralph > On Jun 5, 2023, at 1:19 PM, Volkan Yazıcı <vol...@yazi.ci> wrote: > > Gary, I think we are not on the same page. I am talking about the > "compiler" version, not the "target" version. The version developers use to > compile the code, not to run the generated bytecode. We can compile with > 17, yet target 11, etc. > > For instance, both `logj4-tools` and `log4j-transform` get compiled with > 17, yet target 8. Hence 8 users can still consume them. > > On Mon, Jun 5, 2023 at 10:00 PM Gary Gregory <garydgreg...@gmail.com> wrote: > >> The latest LTS always view is not realistic if you want users to migrate to >> our latest version. My experience is that this will only achieve excluding >> apps from migrating because updating the underlying Java platform is >> non-trivial for larger enterprise grade stacks. >> >> Gary >> >> On Mon, Jun 5, 2023, 14:39 Volkan Yazıcı <vol...@yazi.ci> wrote: >> >>> I don't have a strong preference for the bytecode version we "target"; 11 >>> or 17 is fine. But I would like to point out that we should move the >>> compiler requirement to Java 17 and preferably always stick to the latest >>> LTS as much as possible. >>> >>> On Mon, Jun 5, 2023 at 6:33 PM 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. >>> >>
