Hi Mickael,
Thanks for the KIP. It’s good to see Kafka take on the PQC world; I had a few
comments.
AK1: nit: but the Status is still marked as Draft and the Discussion Link is
still TBD
AK2: The reflection mechanism could use some details. Are we storing a
MethodHandle reference when DefaultSslEngineFactory initializes in a static
block?
AK3: If the contract is to throw ConfigException because of missing names group
support on the jdk, there’s nothing in the SslEngineFactory to have other
engines follow the spec. ssl.engine.factory.class for other engines won’t
adhere to this, and may break silently after launch.
AK4: Should we file a JIRA in conjunction to deprecate/cleanup the reflection
once all clients and servers update their minimum supported version >= 20?
AK5:
> a TLS connection can only be established when the client and server share at
> least one named group
I see in other replies than this would this be an sslhandshakexception that the
jdk SSLEngine throws. Would it be worth adding a custom KafkaException that
suggests to users on the supported named groups in the current VM via
SSLContext.getSupportedSSLParameters().getNamedGroups(). We sometimes do this
when serialization fails, max poll interval elapses etc.
AK6: On Testing, there’s a negative test that we’re missing. We can ensure
assertThrows(ConfigException.class) on jdk versions < 20 which maybe a lot of
the clients out there.
AK7: I think for the simplicity alone, reflection is what we might settle on.
But I wanted to call out that there’s technically another approach that might
get us there without it.
We could do a multi-release JAR which has been available since jdk9. We can
create a custom java20 source set and have gradle include it in the build.
We can define a plain class on the base layer as
```java
public class NamedGroupSupport {
public boolean supported() { return false; }
public void apply(SSLParameters sslParams, String[] groups) { throw new
UnsupportedOperationException(); }
}
```
And in the java20 source set, have the right implementation. We also need
```groovy
jar {
into(‘META-INF/versions/20’) { from sourceSets.java20.output }
manifest { attributes ‘Multi-Release’: ‘true’ }
}
```
With the above in addition to a custom java20 source set with options.release =
20 could get us there for free.
But the cost is the build complexity, if someone shades the kafka-clients JAR
they lose support. Also for clients who fork and build their own JARs this
would not be preferable. So overall, reflection is the simpler answer I think
but an alternative nonetheless to reject imo.
Thanks,
Aditya Kousik
On 2026-10-06 10:14 UTC Mickael Maison wrote:
> Hi,
>
> I'd like to start a discussion about KIP-1376 which proposes adding
> support for TLS named groups:
> https://cwiki.apache.org/confluence/x/dJXwGg
>
> Thanks,
> Mickael
>
