Re: [DISCUSSION][JAVA] Current state of Java 17 support

[Reuven Lax via dev]

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 
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 
> wrote:
>
>> This is a good heads up, thank you Cristian.
>>
>> On Thu, Dec 1, 2022 at 8:13 AM Cristian Constantinescu 
>> 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 
>>> 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 
>>> 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 
>>> 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 

Re: [DISCUSSION][JAVA] Current state of Java 17 support

[Luke Cwik via dev]

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

> This is a good heads up, thank you Cristian.
>
> On Thu, Dec 1, 2022 at 8:13 AM Cristian Constantinescu 
> 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  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 
>> 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 
>> 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
>> 

Re: [DISCUSSION][JAVA] Current state of Java 17 support

[Sachin Agarwal via dev]

This is a good heads up, thank you Cristian.

On Thu, Dec 1, 2022 at 8:13 AM Cristian Constantinescu 
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  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 
> 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  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
> >>
> >>
>

Re: [DISCUSSION][JAVA] Current state of Java 17 support

[Cristian Constantinescu]

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  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  
> wrote:
>>
>>
>> On 30 Nov 2022, at 03:56, Tomo Suzuki via dev  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  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  
>>> 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
>>
>>

Re: [DISCUSSION][JAVA] Current state of Java 17 support

[Kenneth Knowles]

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

>
> On 30 Nov 2022, at 03:56, Tomo Suzuki via dev  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  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
>
>
>

Re: [DISCUSSION][JAVA] Current state of Java 17 support

[Alexey Romanenko]

> On 30 Nov 2022, at 03:56, Tomo Suzuki via dev  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  > 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 > > 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

Re: [DISCUSSION][JAVA] Current state of Java 17 support

[Tomo Suzuki via dev]

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

Regards,
Tomo

On Tue, Nov 29, 2022 at 21:48 Austin Bennett  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 
> 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

Re: [DISCUSSION][JAVA] Current state of Java 17 support

[Austin Bennett]

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

[DISCUSSION][JAVA] Current state of Java 17 support

[Alexey Romanenko]

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