Thank you all for the inputs. I see we currently have agreements on 1. bumping straight to Java 17 for the build system.
For the concern for > (we need to be sure we don't rely on pieces of the standard library that are missing in JRE8) in Java9+ `--release 8` javac flag does exactly this, and beam already set this flag if build in Java9+ [1] 2. It's not time to drop Java 8 support in the near future, and we should continue testing on Java8 compatibility until then. [1] https://github.com/apache/beam/blob/8a4a250076bde59fadb89b2e580e6e98d064b26d/buildSrc/src/main/groovy/org/apache/beam/gradle/BeamModulePlugin.groovy#L1147 On Mon, Jul 1, 2024 at 11:50 AM Danny McCormick via dev <dev@beam.apache.org> wrote: > ;tldr - I think we are too early to drop Java 8 support, and that means we > need to keep building/testing Java 8. > > > 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)? > > +1 on bumping straight to Java 17 - it seems like we don't gain a whole > lot by moving to 11 comparatively. > > > 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?) > > Agreed. One option is to run selected suites against both Java 8, 11, and > 17 (which we already do, this would just consolidate the build step). > > > 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. > > +1 - I would prefer avoiding this until we *have *to (e.g. if > dependencies drop support). > > > 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? > > Some useful data points here: > > - Temurin Java 8 support is through the end of 2026 [1] > - Protobuf Java 8 support is through 2027 Q1 [2] > - Oracle Java 8 Extended Support is through 2030 Q4 [3] > - Spark will continue to support Java 8 through 2030 [4] > - Flink Java 8 support is alive, but deprecated [5] > > I think we are too early to drop Java 8 support, so we need to keep > testing it. > > Thanks, > Danny > > [1] https://adoptium.net/support/ > [2] > https://cloud.google.com/java/docs/supported-java-versions#keeping_production_systems_current > [3] https://endoflife.date/oracle-jdk > [4] > https://community.cloudera.com/t5/Community-Articles/Spark-and-Java-versions-Supportability-Matrix/ta-p/383669 > [5] > https://nightlies.apache.org/flink/flink-docs-release-1.19/docs/deployment/java_compatibility/ > > > > On Mon, Jun 24, 2024 at 8:00 PM Robert Bradshaw via dev < > dev@beam.apache.org> wrote: > >> 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 >> >> >> >> >> >
