Another thing to keep in mind is that Java is moving to biannual releases and Long Term Support vs non-LTS with Java 9+. We'll need a strategy of how to handle the new release schedule as it may not even make sense to support the non-LTS versions.
What if we had a policy like: - Only use LTS Java Versions for the core codebase - Make the latest LTS Java version the codebase standard 1 year following the release of that LTS version - Support development on non-LTS versions in individual bundles This would have us: - Upgrade to Java 8 for ongoing development (since Java 9 is not LTS) - Upgrade to Java 11 in September 2019 - Upgrade to Java 17 (the next LTS) on September 2022 WDYT? On Thu, Jul 5, 2018 at 7:43 AM Eugen Stan <[email protected]> wrote: > Hi, > > There are good arguments to both sides. If it comes to a vote, I'm all > in for moving baseline to Java 8 in one swoop. It makes things simpler. > > There are great many API improvements that we could benefit from: > streams, lamdas, date time API, collections improvements, Optional > updates, etc. > > Regards, > > > On 05.07.2018 11:43, Bertrand Delacretaz wrote: > > Hi Jason, > > > > On Wed, Jul 4, 2018 at 9:27 PM Jason E Bailey <[email protected]> wrote: > >> ...1. I would not consider using or not using java 8's lambda's a > "programming comfort" > >> the paradigms introduced with Java 8 such as lambda's and streams > fundamentally > >> change how the source is written and in my experience results in > concise, easier > >> to understand code... > > I agree! > > > > But if you're making a minor change to an existing core bundle it > > might be better to stick to the current Java version that's used for > > that bundle, instead of changing just because a few lines look nicer. > > > > I guess it's a question of balance between what "minor changes" and > > "better code" are. > > > > The most recent discussion that I found about that is this one > > > > > https://lists.apache.org/thread.html/0bdd59ec761ec07a3fc35144cf9fa9b318496dbc78958127515799b8@%3Cdev.sling.apache.org%3E > > > > where we seemed to have consensus about moving individual bundles to > > Java 8 (as opposed to making that the default, for now) if that brings > > tangible benefits. > > > > At this point I see two options: > > > > a) Continue moving individual bundles as needed, and IMHO it's good to > > do a 72-hours [LAZY] vote before changing core bundles like engine, > > API etc. > > > > b) Revisit that discussion and make Java 8 the default in the parent pom > > > > I don't have strong opinions myself, I just want such decisions to be > > made explicitly by this PMC and community. > > > > -Bertrand > > >
