You can also see this from these lines of the stack trace java.base/javax.security.auth.Subject.getSubject(Subject.java:277) org.apache.kafka.common.security.authenticator.SaslClientCallbackHandler.handle(SaslClientCallbackHandler.java:58)
In Kafka 4.0.0, that line in the callback handler isn't calling Subject.getSubject https://github.com/apache/kafka/blob/4.0.0/clients/src/main/java/org/apache/kafka/common/security/authenticator/SaslClientCallbackHandler.java#L58 So you're almost certainly not using the Kafka 4.0.0 code. Den tors. 21. aug. 2025 kl. 10.47 skrev Stig Rohde Døssing < stigdoess...@gmail.com>: > Your stack trace suggests that you aren't actually using Kafka 4.0.0. > > The relevant code in 4.0.0 is here > https://github.com/apache/kafka/blob/4.0.0/clients/src/main/java/org/apache/kafka/common/security/authenticator/SaslClientAuthenticator.java#L221 > > As you can see, the line number doesn't match what you have in your trace > (221 in the code vs 220 in your trace) > > Instead, it matches the code as it appeared earlier in e.g. 3.8.1 > https://github.com/apache/kafka/blob/3.8.1/clients/src/main/java/org/apache/kafka/common/security/authenticator/SaslClientAuthenticator.java#L220 > > I'd make sure that you're actually using solely Kafka 4.0.0 jars. > > Den tors. 21. aug. 2025 kl. 08.11 skrev Subra I <iamsubra...@gmail.com>: > >> Are there any issues with running the kafka 4.0.0 client on graalVM JDK >> 24? >> My Java codebase uses GraalVM JDK 24 and I continue to get the following >> error: >> >> Caused by: org.apache.kafka.common.errors.SaslAuthenticationException: >> Failed to configure SaslClientAuthenticator >> Caused by: java.lang.UnsupportedOperationException: getSubject is not >> supported >> at java.base/javax.security.auth.Subject.getSubject(Subject.java:277) >> at >> >> org.apache.kafka.common.security.authenticator.SaslClientCallbackHandler.handle(SaslClientCallbackHandler.java:58) >> at >> >> java.security.sasl/com.sun.security.sasl.ClientFactoryImpl.getUserInfo(ClientFactoryImpl.java:138) >> at >> >> java.security.sasl/com.sun.security.sasl.ClientFactoryImpl.createSaslClient(ClientFactoryImpl.java:96) >> at >> >> java.security.sasl/javax.security.sasl.Sasl.createSaslClient(Sasl.java:429) >> at >> >> org.apache.kafka.common.security.authenticator.SaslClientAuthenticator.lambda$createSaslClient$0(SaslClientAuthenticator.java:220) >> at >> >> java.base/jdk.internal.vm.ScopedValueContainer.callWithoutScope(ScopedValueContainer.java:162) >> at >> >> java.base/jdk.internal.vm.ScopedValueContainer.call(ScopedValueContainer.java:147) >> >> On Thu, Aug 21, 2025 at 12:03 AM Stig Rohde Døssing < >> stigdoess...@gmail.com> >> wrote: >> >> > Subra, >> > >> > This should be fixed with >> > https://issues.apache.org/jira/browse/KAFKA-17078. >> > >> > Den ons. 20. aug. 2025 kl. 19.43 skrev Subra I <iamsubra...@gmail.com>: >> > >> > > I understand that this was slated to fixed. as per this KIP: >> > > >> > > >> > >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1006%3A+Remove+SecurityManager+Support >> > > >> > > Has this been fixed in kafka 4.0.0 client? Basically, being able to >> > handle >> > > removal of SecurityManager in JDK. >> > > >> > > On Wed, Aug 20, 2025 at 7:22 PM Subra I <iamsubra...@gmail.com> >> wrote: >> > > >> > > > Hello All, >> > > > >> > > > We have a codebase on Java where we create a kafka >> producer/consumer to >> > > > talk to kafka brokers. We support TCP/SSL/SASL modes of operation >> for >> > > kafka. >> > > > >> > > > We are upgrading our environment to JDK 24. And I see that is >> causing >> > our >> > > > SASL functionalities to break. >> > > > >> > > > I am using kafka client version 3.9.0. How do we support SASL with >> JDK >> > 24 >> > > > and above? Can I use kafka 4.0.0 client? Even with that, this >> > > > functionality is not working. >> > > > >> > > > Please advise. >> > > > Thanks, >> > > > Subra >> > > > >> > > > On Wed, Apr 2, 2025 at 11:53 AM Jan Vissers <visser...@gmail.com> >> > wrote: >> > > > >> > > >> Hi, >> > > >> >> > > >> Keeping our fingers crossed for this backport to make it into 3.9. >> > > >> >> > > >> We are using Kafka client as a 3rd, and 4th party dependency >> (through >> > > >> Confluent Parallel Consumer - @astubbs), in a collection of >> Helidon MP >> > > >> 4.1.6 microservices. >> > > >> >> > > >> When do you estimate would we know for sure whether it will be in? >> > > >> >> > > >> Thanks. >> > > >> - Jan. >> > > >> >> > > >> >> > > >> On 2025/03/17 17:14:21 Stig Rohde Døssing wrote: >> > > >> > Thanks Ismail, >> > > >> > >> > > >> > I've opened https://github.com/apache/kafka/pull/19221 just to >> get >> > > any >> > > >> test >> > > >> > failures out of the way in case it is decided to do this >> backport. >> > > >> > >> > > >> > I'm hoping people will weigh in with their concerns in this >> thread >> > if >> > > >> they >> > > >> > don't like the idea of backporting this change. >> > > >> > >> > > >> > Den man. 17. mar. 2025 kl. 16.43 skrev Ismael Juma < >> > > >> me...@ismaeljuma.com>: >> > > >> > >> > > >> > > Hi Stig, >> > > >> > > >> > > >> > > Kafka 4.0 is likely to be released in a day or two. Even so, I >> > think >> > > >> it >> > > >> > > makes sense to revive the backporting thread given the lack of >> > > >> workaround >> > > >> > > for Java 24. >> > > >> > > >> > > >> > > Ismael >> > > >> > > >> > > >> > > On Mon, Mar 17, 2025 at 7:44 AM Stig Rohde Døssing < >> > > >> stigdoess...@gmail.com >> > > >> > > > >> > > >> > > wrote: >> > > >> > > >> > > >> > > > Hi, >> > > >> > > > >> > > >> > > > Some months ago, a reflective shim was added in >> > > >> > > > https://issues.apache.org/jira/browse/KAFKA-17078, in order >> to >> > > >> support >> > > >> > > > running Kafka with SASL on JDKs that no longer support the >> > > security >> > > >> > > > manager. >> > > >> > > > >> > > >> > > > This shim was added only to Kafka 4.0, but backporting was >> > > discussed >> > > >> in >> > > >> > > > >> > https://lists.apache.org/thread/vl43q9wqq4xs67xx61f0t0850y2b037o. >> > > >> There >> > > >> > > > was >> > > >> > > > no clear consensus for or against backporting, but it ended >> up >> > not >> > > >> > > > happening. At the time, users could work around the issue by >> > > >> enabling >> > > >> the >> > > >> > > > Security Manager again via a command-line flag. >> > > >> > > > >> > > >> > > > Java 24, which is planned to release tomorrow, no longer has >> > this >> > > >> > > > workaround available. >> > > >> > > > >> > > >> > > > This leaves users running Java 23 (I am one) in a slightly >> > > >> uncomfortable >> > > >> > > > spot. >> > > >> > > > >> > > >> > > > If Kafka releases 4.0 in the next month, we can rush to >> upgrade >> > to >> > > >> that, >> > > >> > > > and hope that the first release has no regressions. >> > > >> > > > >> > > >> > > > Otherwise, we will need to downgrade back to Java 21, since >> > > staying >> > > >> on 23 >> > > >> > > > isn't a good idea past Oracle's quarterly security update in >> > April >> > > >> (see >> > > >> > > > https://www.oracle.com/security-alerts/), which will include >> > > >> patches >> > > >> > > that >> > > >> > > > won't be released for Java 23. >> > > >> > > > >> > > >> > > > Would there be strong objections to attempting a backport of >> > this >> > > >> shim >> > > >> > > to a >> > > >> > > > 3.9.x release? >> > > >> > > > >> > > >> > > >> > > >> > >> > > >> >> > > > >> > > >> > >> >
