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