...

For example, if SecurityManager is removed from the Kafka codebase in 4.0, and SecurityManager is removed from Java 25, users of Kafka 4.x can immediately upgrade to Java 25 without special considerations.

However, there are some problems with removing support quicklyconstraints on how early we can remove support:

1. Java 11 still has the non-deprecated SecurityManager, and Kafka 4.0 must support Java 11. If we were to remove SecurityManager support from Kafka 4.0, users on Java 11 would experience a removal without a prior deprecation.
2. Java 17 does not have the replacement Subject API https://bugs.openjdk.org/browse/JDK-8267108 , and Kafka 4.0 must support Java 17. We would need dual support for the old and new APIs.

Therefore, we will plan to remove SecurityManager support in the Kafka major version which drops support for JDK 17.

We can notify users of this removal with a log message, and with a notice in the Kafka documentationThe earliest we could remove the SecurityManager without tech-debt is when Java 21 could become the minimum supported Java version. This is not planned for Kafka currently, but would probably be Kafka >=6.0.

Remove compile-time usages & detect SecurityManager removal at runtime

The longer it takes for Kafka to remove SecurityManager support, the more likely that the Java removal will take place before Kafka's removal is complete. To be prepared, we should anticipate that the project will need to support both versions with and without SecurityManager, using the same codebase & artifacts.

In an upcoming minor release after this KIP, the deprecated calls will be changed to use reflection. If the legacy APIs are available, they will be used. If not, the modern APIs will be called reflectively.

In the major release which removes SecurityManager support, the reflection will be This can be done by replacing direct references to deprecated APIs with reflection, and gracefully changing the behavior for Java versions without the SecurityManager. When Java 21 becomes the minimum supported Java version, the reflective implementations could be removed and replaced with direct calls to the modern APIAPIs.

Proposed Changes

The SaslClientCallbackHandler and OAuthBearerSaslClientCallbackHandler A static utility in clients  will no longer call Subject.getSubject , and instead will use the JDK 18+ Subject.current API: https://bugs.openjdk.org/browse/JDK-8267108 .
The SaslClientAuthenticator and SaslServerAuthenticator in clients will use the Java 18+ Subject.callAs API rather than the deprecated Subject.doAs function. This has a backwards-compatible implementation that will presumably be replaced when SecurityManager is removed.
The calls to getSubject, current, doAs, and callAs will be replaced with reflection. If Java 18 is available, the new functions will be used. Otherwise, the legacy API will be called.The calls to AccessController.doPriviliged  in core  and connect:runtime: used for ClassLoader instantiation will be replaced with reflection. If the doPriviliged call is not available, the privileged operations will be done in the original context. will reflectively examine the presence or absence of the legacy and modern implementations.

If it finds that the legacy implementation is available, it will use it. If not, the modern implementation is substituted.

Compatibility, Deprecation, and Migration Plan

...

This should be delegated to another KIP with a dedicated discussion. This KIP can be blocked on that one, or be conditional. For example, we can agree here that in the major release which removes Java 17 support, we will also remove SecurityManager support, but not specify when the removal of Java 17 support will take place, and the removal of SecurityManager support can be included in whatever version changes the minimum java version to 21.

Implement a alternative to the SecurityManager for use with Kafka

...