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