...
Since removing SecurityManager is a breaking change, we would have to either delay support for the new Java version significantly, or perform a major release of Kafka when we might not be prepared for it. These negatives outweigh the maintenance burden of making these function calls reflective.
Add the reflective utility, but follow the Java upstream's removal schedule
The reflective utility is a harmful piece of tech debt, and should be removed as early as possible. If we do not remove SecurityManager support in the Kafka project, we will be required to maintain the reflective utility until we no longer support JREs that have the SecurityManager.
For example, if Java 25 removes SecurityManager, we would need to maintain the reflective utility until Java 25 is the minimum supported version, which could be several years after Java 21 becomes the minimum supported version. If the upstream decides to remove SecurityManager support later, the Kafka project would be responsible for the tech debt for longer as well.
Removing our support for SecurityManager gives us control over the timeline with which to pay off this tech debt, and supports the Java community's goal of removing the functionality promptly.
Set a removal date for Java 11 / Java 17 support
...