Hi Ismael, Thanks for your question
> Greg, why can't we set the relevant system property > automatically for the broker/connect in 3.9.x? The System property workaround is not effective for Java 24, and doesn't cover the kafka-as-a-library use-case, which is the one which is generating pain for our users. We already have a patch reviewed and merged which can fix this generally (23/24, clients/streams/brokers/connect), and is low risk. Please review the PR to convince yourself of this. > When it comes to usage of > Kafka as a library (eg clients), I very much doubt kafka will be the only > system that requires this system property to be set, so not sure how much > it matters. I don't think other libraries' support for SecurityManager is relevant to this discussion, as there almost certainly is a downstream project out there for which Kafka is the only dependency blocking their upgrade. And if all libraries took that strategy, that would harm the adoption of Java 23 and users, so we should avoid implementing that strategy ourselves. Thanks, Greg On Thu, Nov 21, 2024 at 7:31 AM Ismael Juma <m...@ismaeljuma.com> wrote: > We had agreed to extend _critical bug fixes_ for one year for 3.9. > Something beyond that would require its own separate discuss thread, it > should not be in the middle of a thread about Java 23 support in 3.9. I am > personally not in favor of a LTS or 18-24 months cycle - it would divert a > lot of resources from the community (vendors are welcome to do that, of > course). > > With regards to having Java 23 work in 3.9.x, that doesn't seem > unreasonable if we can do so via a low risk change (especially since 3.9.0 > was just released). Greg, why can't we set the relevant system property > automatically for the broker/connect in 3.9.x? When it comes to usage of > Kafka as a library (eg clients), I very much doubt kafka will be the only > system that requires this system property to be set, so not sure how much > it matters. > > Ismael > > On Thu, Nov 21, 2024 at 1:51 AM Josep Prat <josep.p...@aiven.io.invalid> > wrote: > > > 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 > > >
