We have run into som JDK-specific issues with our use of ByteBuddy though. On Thu, Dec 1, 2022 at 3:43 PM Luke Cwik via dev <dev@beam.apache.org> wrote:
> We do support JDK8, JDK11 and JDK17. Our story around newer features > within JDKs 9+ like modules is mostly non-existent though. > > We rarely run into JDK specific issues, the latest were the TLS1 and > TLS1.1 deprecation in newer patch versions of the JDK and also the docker > cpu share issues with different JDK versions. Even though it would be nice > to cover more, we currently have too many flaky tests and an already busy > Jenkins cluster. I believe we would get a lot more value out of deflaking > our existing tests and re-enabling disabled tests. > > I got to give credit to the JDK folks for how well they have maintained > compatibility over the years. > > On Thu, Dec 1, 2022 at 9:05 AM Sachin Agarwal via dev <dev@beam.apache.org> > wrote: > >> This is a good heads up, thank you Cristian. >> >> On Thu, Dec 1, 2022 at 8:13 AM Cristian Constantinescu <zei...@gmail.com> >> wrote: >> >>> Hi, >>> >>> I came across some Kafka info and would like to share for those >>> unaware. Kafka is planning to drop support for Java 8 in Kafka 4 (Java >>> 8 is deprecated in Kafka 3), see KIP-750 [1]. >>> >>> I'm not sure when Kafka 4 is scheduled to be released (probably a few >>> years down the road), but when it happens, KafkaIO may not be able to >>> support it if we maintain Java 8 compatibility unless it remains on >>> Kafka 3. >>> >>> Anyways, if not already done, I think it's a good idea to start >>> putting up serious warning flags around Beam used with Java 8, even >>> for Google cloud customers ;) >>> >>> Cheers, >>> Cristian >>> >>> [1] https://issues.apache.org/jira/browse/KAFKA-12894 >>> >>> On Wed, Nov 30, 2022 at 12:59 PM Kenneth Knowles <k...@apache.org> >>> wrote: >>> > >>> > An important thing is to ensure that we do not accidentally depend on >>> something that would break Java 8 support. >>> > >>> > Currently our Java 11 and 17 tests build the code with Java 8 (just >>> like our released artifacts) and then compile and run the test code with >>> the newer JDK. This roughly matches the user scenario, I think. So it is a >>> little more complex than just having separate test runs for different JDK >>> versions. But it would be good to make this more symmetrical between JDK >>> versions to develop the mindset that JDK is always explicit. >>> > >>> > Kenn >>> > >>> > On Wed, Nov 30, 2022 at 9:48 AM Alexey Romanenko < >>> aromanenko....@gmail.com> wrote: >>> >> >>> >> >>> >> On 30 Nov 2022, at 03:56, Tomo Suzuki via dev <dev@beam.apache.org> >>> wrote: >>> >> >>> >> > Do we still need to support Java 8 SDK? >>> >> >>> >> Yes, for Google Cloud customers who still use Java 8, I want Apache >>> Beam to support Java 8. Do you observe any special burden maintaining Java >>> 8? >>> >> >>> >> >>> >> I can only think of the additional resources costs if we will test >>> all supported JDKs, as Austin mentioned above. Imho, we should do that for >>> all JDK that are officially supported. >>> >> Another less-costly way is to run the Java tests for all JDKs only >>> during the release preparation stage. >>> >> >>> >> I agree that it would make sense to continue to support Java 8 until >>> a significant number of users are using it. >>> >> >>> >> — >>> >> Alexey >>> >> >>> >> >>> >> >>> >> Regards, >>> >> Tomo >>> >> >>> >> On Tue, Nov 29, 2022 at 21:48 Austin Bennett <aus...@apache.org> >>> wrote: >>> >>> >>> >>> -1 for ongoing Java8 support [ or, said another way, +1 for dropping >>> support of Java8 ] >>> >>> >>> >>> +1 for having tests that run for ANY JDK that we say we support. Is >>> there any reason the resources to support are too costly [ or outweigh the >>> benefits of additional confidence in ensuring we support what we say we do >>> ]? I am not certain on whether this would only be critical for releases, >>> or should be done as part of regular CI. >>> >>> >>> >>> On Tue, Nov 29, 2022 at 8:51 AM Alexey Romanenko < >>> aromanenko....@gmail.com> wrote: >>> >>>> >>> >>>> Hello, >>> >>>> >>> >>>> I’m sorry if it’s already discussed somewhere but I find myself a >>> little bit lost in the subject. >>> >>>> So, I’d like to clarify this - what is a current official state of >>> Java 17 support at Beam? >>> >>>> >>> >>>> I recall that a great job was done to make Beam compatible with >>> Java 17 [1] and Beam already provides “beam_java17_sdk” Docker image [2] >>> but, iiuc, Java 8 is still the default JVM to run all Java tests on Jenkins >>> ("Java PreCommit" in the first order) and there are only limited number of >>> tests that are running with JDK 11 and 17 on Jenkins by dedicated jobs. >>> >>>> >>> >>>> So, my question would sound like if Beam officially supports Java >>> 17 (and 11), do we need to run all Beam Java SDK related tests (VR and IT >>> test including) against all supported Java SDKs? >>> >>>> >>> >>>> Do we still need to support Java 8 SDK? >>> >>>> >>> >>>> In the same time, as we are heading to move everything from Jenkins >>> to GitHub actions, what would be the default JDK there or we will run all >>> Java-related actions against all supported JDKs? >>> >>>> >>> >>>> — >>> >>>> Alexey >>> >>>> >>> >>>> [1] https://issues.apache.org/jira/browse/BEAM-12240 >>> >>>> [2] https://hub.docker.com/r/apache/beam_java17_sdk >>> >>>> >>> >>>> >>> >>>> >>> >> -- >>> >> Regards, >>> >> Tomo >>> >> >>> >> >>> >>
