Hi everyone, We recently upgraded our Flink version from

1.15

to

1.18

in our AWS Kinesis (AWS Managed Apache Flink) environment. While Flink 1.18 is supposed to support Java 17, we are encountering issues when deploying Java 17 applications. The applications still work with Java 11 but fail with Java 17 with this error:

Caused by: java.lang.UnsupportedClassVersionError: <class_name> has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0

It appears that AWS is supplying JRE 11, and we don’t see any options in the AWS console to choose the Java Runtime.. Has anyone else experienced similar issues with AWS Managed Apache Flink and Java 17? Any insights or workarounds would be greatly appreciated. We are also in contact with AWS support but are looking for any additional guidance from the community. Thank you!

You could run your own EC2 instance or consider using a solution like decodable.co

Thank you for the suggestions. We are evaulating these options currently. Also, we would like to to explore quicker and less disruptive solutions since we have multiple pipelines running in Kinesis and it would take a large effort to migrate these over.

Was also discussing in my team to upgrade our managed aws flink jobs to use Java 17, but noticed that on aws they still recommend to use 11 🤯 https://docs.aws.amazon.com/managed-flink/latest/java/flink-1-19.html#flink-1-19-1-components Wonder if they will ever support 17 or what the thinking behind it is

@Louis Cameron Booth Yes we noticed that document mentioning Java 11 is recommended. We are reaching out to AWS support 🤞

Hey. I'm from Decodable. The challenge with Java 17 is that there are still some parts of Flink (and the libraries and jvm features it uses) that aren't entirely stable or well-tested under Java 17. Most of this has been worked out, IIRC, but consensus is that it needs production burn-in time. That's why you see most folks unable to support it. We still see lots of folks developing with Java 17 and targeting Java 11 bytecode (i.e.

--target 11

).

Thank you for the info. yeah, we'll probably do the same for now (use target version 11)