JDK 17 EA build 26 - Better debuggability of SecurityManager WARNING messages?

[Jaikiran Pai]

While testing the Apache Ant project with the latest released EA of JDK 
17[1] (build 26), at least one of our internal test case has started 
failing. The failure relates to the new "WARNING" message that gets 
printed out to System.err when some code at runtime sets the security 
manager. The test case we have expects that the System.err stream 
contains only specific content. However, with this change, it now finds 
the expected content plus this additional warning message:

WARNING: java.lang.System::setSecurityManager is deprecated and will be 
removed in a future release.

Given the way the test is written, it doesn't like the presence of this 
additional content on System.err and fails.

"Fixing" this test itself is pretty trivial for us and given that it's 
just one such test, I plan to just go ahead and do that tomorrow. 
However, what I'm more interested in is what part of the code at runtime 
is setting the security manager. I think even that part I can probably 
easily narrow it down tomorrow once I look into the code. But from what 
I imagine, this is going to be much more difficult to narrow down if the 
security manager is being set at runtime from third party library code, 
deep in the ecosystem of the deployed application (imagine some code 
embedding Ant project and invoking it from their project).

I understand that the -Djava.security.manager system property allows the 
values "allow" and "disallow", but additionally would it be possible to 
introduce a new (optional) system property which takes a value "debug"? 
When this system property is set to "debug" and the Java runtime detects 
that a WARNING needs to be issued because of runtime setting of security 
manager, then a stacktrace is dumped showing the call location of each 
such code which is setting the security manager? This would be similar 
to the --illegal-access flag (although not a system property) that had 
the "debug" option, which I thought proved to be very useful when 
narrowing down the reflective access calls.


[1] https://jdk.java.net/17/

-Jaikiran