Hello, I also think this sounds like a reasonable suggestion, also given that 3.9 was the first version to make KRaft feature complete, which means it's the first version to bring production readiness for KRaft, in many contexts.
+1 from me. BR, Den tors 21 nov. 2024 kl 10:51 skrev Josep Prat <josep.p...@aiven.io.invalid >: > Hi all, > Given 3.9 is the latest version before a major, and 4.0.0 comes with > breaking changes (Zookeeper removal, Scala and Java version drops...) I > think it's fair to assume that a considerable subset of Kafka users will be > using 3.9 for a little longer than we usually support versions (roughly 1 > year). I would be in favour of considering 3.9 as and LTS and offer support > for, let's say 18 to 24 months. > In that spirit, I would be in favour of releasing a future 3.9 version that > can run with JDK 23. > > Best, > > On Thu, Nov 21, 2024 at 3:46 AM Chia-Ping Tsai <chia7...@gmail.com> wrote: > > > Dear all, > > > > It seems the main question is whether we should consider version 3.9 as > an > > LTS release. For example, will we continue with versions like 3.9.1, > 3.9.2, > > ... 3.9.100? > > > > If yes, we should backport both KIP-1006 and support for future JDKs. > > > > If not, backporting KIP-1006 to 3.9 would be sufficient to fix the issue > of > > running version 3.9 under JDK 23, even if JDK 23 is still not officially > > supported by 3.9. > > > > > > Best, > > > > Chia-Ping > > > > > > > > Greg Harris <greg.har...@aiven.io.invalid> 於 2024年11月21日 週四 上午4:37寫道： > > > > > > Has the SecurityManager been fully removed in JDK 23? > > > > What is the effect of running Kafka 3.9.0 with JDK 23? > > > > > > The SecurityManager has been degraded, so by default our users > experience > > > an UnsupportedOperationException. They can work-around this by setting > a > > > system property. > > > In JRE 24, JEP-486 [1] has removed this workaround, so an unpatched > 3.9.x > > > will experience an UnsupportedOperationException unconditionally. > > > > > > > I see https://issues.apache.org/jira/browse/KAFKA-17638 > > > > which explicitly adds JDK 23 to our CI with a fix version of 4.0.0. > > Lack > > > of > > > > support for JDK 23 in 3.9.x is not a bug, it is what we planned (as > far > > > as > > > > I can tell). > > > > > > Originally we were planning to get this change into 3.9.0, but we > missed > > > the merge deadline. I opened that ticket afterwards to be fixed in > 4.0.0 > > > because that's the next release. > > > The patch was always intended to be backportable, and I intended to > > > backport it [2]. > > > > > > I understand that if we consider Java 23 support to be a feature (which > > is > > > the standing decision), this is a pretty obvious case of missing > feature > > > freeze, and the current course of action (releasing in 4.0.0) is how we > > > would handle it. > > > I'm asking for this to be reconsidered as a bug fix, because it allows > us > > > to backport the change, which is what our users are asking for [3]. > > > > > > Thanks, > > > Greg > > > > > > [1] https://openjdk.org/jeps/486 > > > [2] https://github.com/apache/kafka/pull/16522#issuecomment-2377340024 > > > [3] https://lists.apache.org/thread/312lm617q05k87kxsrwlqhk8rfg29t7g > > > > > > On Wed, Nov 20, 2024 at 11:50 AM David Arthur <mum...@gmail.com> > wrote: > > > > > > > Greg, > > > > > > > > I have not been following this closely, so apologies for some basic > > > > questions. > > > > > > > > Has the SecurityManager been fully removed in JDK 23? > > > > > > > > What is the effect of running Kafka 3.9.0 with JDK 23? > > > > > > > > By "4.0 breaking changes" do you mean changes to our JDK/Scala > > supported > > > > versions, removal or ZK, Kafka API changes, or something else? > > > > > > > > In general, I do not think we should change our supported JDK > versions > > > in a > > > > hotfix release. I see > > https://issues.apache.org/jira/browse/KAFKA-17638 > > > > which explicitly adds JDK 23 to our CI with a fix version of 4.0.0. > > Lack > > > of > > > > support for JDK 23 in 3.9.x is not a bug, it is what we planned (as > far > > > as > > > > I can tell). > > > > > > > > Also, I feel that we should not add too much to 3.9.x aside from > actual > > > > bugs. If we backport things into 3.9.x, it will slow adoption of 4.x > > and > > > > increase our maintenance burden over time. > > > > > > > > Just my $0.02 > > > > > > > > Thanks! > > > > David A > > > > > > > > On Wed, Nov 20, 2024 at 12:22 PM Greg Harris > > > <greg.har...@aiven.io.invalid > > > > > > > > > wrote: > > > > > > > > > Hi all, > > > > > > > > > > Now that 3.9.0 is released and 4.0.x is progressing, I'd like to > > > > understand > > > > > everyone's expectations about the 3.9.x branch, and ask for a > > specific > > > > > consensus on Java 23 support. > > > > > > > > > > Some context that I think is relevant to the discussion: > > > > > * KIP-1006 [1] proposes a backwards-compatible strategy for > handling > > > the > > > > > ongoing removal of the SecurityManager, which is merged and due to > > > > release > > > > > in 4.0.0 [2]. > > > > > * KIP-1012 [3] rejected ongoing parallel feature development on a > 3.x > > > > > branch while having trunk on 4.x. > > > > > * During the 3.9.0 release, the patch [2] was rejected [4] due to > > > being a > > > > > new feature which did not meet the feature freeze deadline. > > > > > * Other than the SecurityManager removal, there are additional PRs > > > which > > > > > would also need to be backported for full Java 23 support [5] > > > including a > > > > > Scala patch upgrade. > > > > > * Downstream users are asking for a backport [6] because adding > > support > > > > for > > > > > Java 23 would obligate them to also include the 4.0 breaking > changes. > > > > > > > > > > So while adding Java version support in the past has been a > KIP-less > > > > > feature and normally only appears in the next version, it happens > to > > > > align > > > > > with a major version bump this time. This will cause additional > pain > > > for > > > > > users if we do not elect to backport this. > > > > > > > > > > Thanks, > > > > > Greg > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1006%3A+Remove+SecurityManager+Support > > > > > [2] https://github.com/apache/kafka/pull/16522 > > > > > [3] > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1012%3A+The+need+for+a+Kafka+3.8+and+3.9+release > > > > > [4] > https://lists.apache.org/thread/xy5rwd1w274qgpwf3qxxnzlqpoly5d4p > > > > > [5] https://issues.apache.org/jira/browse/KAFKA-17638 > > > > > [6] > > https://github.com/apache/kafka/pull/16522#issuecomment-2488340682 > > > > > > > > > > > > > > > > > -- > > > > David Arthur > > > > > > > > > > > > -- > [image: Aiven] <https://www.aiven.io> > > *Josep Prat* > Open Source Engineering Director, *Aiven* > josep.p...@aiven.io | +491715557497 > aiven.io <https://www.aiven.io> | <https://www.facebook.com/aivencloud > > > <https://www.linkedin.com/company/aiven/> < > https://twitter.com/aiven_io> > *Aiven Deutschland GmbH* > Alexanderufer 3-7, 10117 Berlin > Geschäftsführer: Oskari Saarenmaa, Hannu Valtonen, > Anna Richardson, Kenneth Chen > Amtsgericht Charlottenburg, HRB 209739 B >
