Java 23 is not LTS (Long Term Support) by Oracle Do we still want to proceed?
Thanks Swikar > On Dec 2, 2024, at 1:07 PM, Greg Harris <greg.har...@aiven.io.invalid> wrote: > > Hi all, > > Thanks for the discussion so far, but I would like to refocus on the > problem at hand. > > Our downstream users are asking for things that come at a cost to us as > maintainers: An exception to our processes, better support for the final > bridge release, and an easier maintenance burden. > > What is our consensus here? Should we disregard our users, and prioritize > ourselves first? > > Thanks, > Greg > > > >> On Thu, Nov 21, 2024 at 12:52 PM Greg Harris <greg.har...@aiven.io> wrote: >> >> Hi Ismael, >> >> Thanks for your responses. >> >>> At the same time, where do we draw the line when it >>> comes to future unreleased Java versions? >> >> I don't think we need to make a determination on that at this time. We are >> making a one-time judgement about backporting a specific patch to a >> specific branch. We should have that discussion as a follow-up. >> >>> Is there evidence of this pain? That would help motivate the case. >> >> A downstream user has already replied to this thread, I'll relink it here >> [1] and the issue they were working on [2]. >> >>> I don't think this is how we evaluate risk/reward, so I disagree with >> your >>> position here. >>> Requiring users to set a system property is far from "harming" them. >>> Nonetheless, if we can reduce friction, it's a good thing, >> >> I think you missed the point of my statement, which was that we can't >> justify our behavior by hiding among other libraries. >> If everyone did that, nobody would ever respond to deprecations. This is >> an antisocial justification, I don't find it convincing, and we should not >> rely on it. >> >> Thanks, >> Greg >> >> [1] https://lists.apache.org/thread/312lm617q05k87kxsrwlqhk8rfg29t7g >> [2] https://github.com/trinodb/trino/issues/23498 >> >>> On Thu, Nov 21, 2024 at 12:16 PM Ismael Juma <m...@ismaeljuma.com> wrote: >>> >>> 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 >>> >>
