Hi Dan, I think would be helpful if someone with the right expertise can help the community with supporting Java 25. I haven't seen any activity on the Dev mailing list on this subject, and also not a FLIP on how to add support for it (if needed), so I doubt that there's anyone really actively working on it at this moment.
Best regards, Martijn Op di 19 mei 2026 om 15:23 schreef Daniel Burrell via user <[email protected]>: > > Hi all, > > I'd like to start a discussion about Java 25 support for Flink, as suggested > by David Anderson on the community Slack channel: > https://apache-flink.slack.com/archives/C03GV7L3G2C/p1778180123814119?thread_ts=1778141099.814779&cid=C03GV7L3G2C. > > Java 25 has been GA for approximately 9 months now, and FLINK-37719 tracks > several open subtasks required for compatibility. I noticed some of those > subtasks have stalled — for example, the Security Manager removal PR was > closed pending a mailing list discussion that doesn't appear to have happened > yet. > > This is becoming a significant blocker for us. We run a monorepo, which means > Flink is currently the sole dependency preventing our entire codebase from > adopting Java 25. We can't afford to hold back our wider systems from Java > 25's performance optimizations and language improvements for an extended > period. We previously experienced a painful lag between Java 17 and 21 > support in Flink, and we're keen to avoid a repeat of that situation, but > this will be the third time our codebase has been stalled due to flink > support of current Java languages. > > We understand this didn't make the 2.3 feature freeze. Could the community > consider targeting Java 25 support for 2.4? Specifically, it would be helpful > to understand: > > 1. Are there any fundamental technical blockers beyond the subtasks listed > in FLINK-37719? > 2. Is anyone actively working on or planning to pick up the remaining items? > 3. What can downstream users like us do to help move this forward — > testing, reviews, or contributing patches? > > We'd strongly prefer to wait for upstream support rather than pursue > alternatives, but we do need some visibility into a realistic timeline so we > can plan accordingly. > > Kind regards > > > Dan B > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. If > you are not the named addressee you must not disseminate, distribute or copy > this e-mail. Please notify us on [email protected] immediately if you have > received this e-mail by mistake and delete this e-mail from your system. If > you are not the intended recipient you are notified that disclosing, copying, > distributing or taking any action in reliance on the contents of this > information is strictly prohibited.
