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
