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 specif
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 diffe
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
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,
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
> 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 resou
> 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, sai
-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 s
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 pro
