;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 > >> > >> >
