On Mon, Jun 24, 2024 at 9:59 AM Kenneth Knowles <k...@apache.org> wrote: > > Step 1 and 2 sound great. (I tried a first step with > https://github.com/apache/beam/pull/29992 but didn't have bandwidth) > > This will make it easier for people to get started with beam without having > to deal with ancient version compatibility and installing old Java, etc. Even > as a minor point, many of our build plugins are out of date because they have > moved on to more modern Java versions.
+1 > Questions: > > - Could Beam move to requiring latest Java to build and just relying on > "--release" flag or "--target" flag to build the artifacts we release? I probably wouldn't track the very latest, but whatever is generally available on relatively modern systems (and +1 to just using --target for artifacts). > (we need to be sure we don't rely on pieces of the standard library that are > missing in JRE8) This would need to be rigorously tested. How to ensure sufficient coverage? (This is where compiling against old SDKs may have an advantage. Or would using --source and --target be sufficient? Or will we still run into issues with our dependencies dropping support for old versions anyway?) > - Can we release multi-release jars to provide updated versions for > different JDK versions? As long as we choose to maintain backwards compatibility with version X, is there any advantage to providing separate artifacts for version Y>X? Seems like it would mostly just complicate things. I also think a bigger open question is how long we will maintain support for Java 8 (11, etc.) Is there a good measure for when the ecosystem (or, more targeted, our users) have moved on? > Kenn > > On Mon, Jun 24, 2024 at 9:44 AM Yi Hu via dev <dev@beam.apache.org> wrote: >> >> Dear Beam developers, >> >> As Java8 has gone through end-of-public-update, many Beam dependencies have >> already deprecated Java8 (see [1]), and dropping Java8 supports are planned. >> >> Beam hasn't deprecated Java8, moreover, currently Beam CI is using Java8 to >> test and release Beam. Referring to other Apache projects, I hereby suggest >> a 3-step process for dropping Java 8 support: >> >> 1. Switch CI to Java11, while retain the byte code compatibility to Java8 >> for Beam releases. Tracked in [1]. >> >> This won't affect Beam developers and users currently on Java8, and can >> be done immediately >> >> 2. Require Java11+ to build Beam, deprecate Java8 support [2]. >> >> This still won't affect Beam users currently on Java8, but for Beam >> developers build custom Beam artifacts, they will need Java11+ >> >> 3. Drop Java8 support >> >> This will affect Beam users. Targeted in a medium-long future date, when >> Beam's major dependencies already dropped Java8 support >> >> There are a few details for further decision >> >> * Java8 has ended premier support in March 2022, the next LTS, Java11 also >> ended premier support in Sept 2023. Should we bump the default Java version >> to 17 for CI at once (while keeping Java8/11 bytecode compatibility for the >> build)? >> >> * Timeline of deprecating Java8. >> I am volunteering to work on [1] which is targeted to Beam 2.58.0; >> naturally (2) would be Beam 2.59.0 or 2.60.0. >> >> Please provide your thoughts on the general process, and highlight >> particular areas of concern. >> >> [1] https://github.com/apache/beam/issues/31677 >> >> [2] https://www.oracle.com/java/technologies/java-se-support-roadmap.html >> >> Regards, >> Yi >> >> -- >> >> Yi Hu, (he/him/his) >> >> Software Engineer >> >>
