Hi Greg, Comments below.
On Thu, Nov 21, 2024 at 8:07 AM Greg Harris <greg.har...@aiven.io.invalid> wrote: > > 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 This is a fair point. At the same time, where do we draw the line when it comes to future unreleased Java versions? There are two possible paths: (1) we focus on the released versions, (2) we have a clear policy for future versions (the upcoming version, the upcoming LTS version, etc.). > and doesn't > cover the kafka-as-a-library use-case, which is the one which is generating > pain for our users. > Is there evidence of this pain? That would help motivate the case. > 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. > I did take a look at the PR and it did not seem low risk to me (it's larger than we'd typically consider for bug fix releases, it includes reflection, etc.). And hence why I was exploring other options. But it's not necessarily high risk either, it's somewhere in between. > 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. > I don't think this is how we evaluate risk/reward, so I disagree with your position here. > 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. Requiring users to set a system property is far from "harming" them. Nonetheless, if we can reduce friction, it's a good thing, Ismael
