Hello Sean,
On 15/06/21 12:19 am, Sean Mullan wrote:
We already are working on improvements to the warning message to show
the class and the source of the code calling
System::setSecurityManager. See
https://bugs.openjdk.java.net/browse/JDK-8268392
I just had a look at that JBS issue and the proposed change. Specifically:
"
Instead, a warning is issued at run time when System::setSecurityManager
is invoked, as follows:
WARNING: A terminally deprecated method in java.lang.System has been called
WARNING: System::setSecurityManager has been called by
com.foo.bar.server (file:/tmp/foobarserver/thing.jar)
WARNING: Please consider reporting this to the maintainers of
com.foo.bar.server
WARNING: System::setSecurityManager will be removed in a future release
"
I think this will help a lot as compared to what is presently logged.
If that is not sufficient and a stack trace is really still needed, my
preference would be to leverage the existing java.security.debug
system property, and add a new value, say "sm" and that would
additionally print a stack trace. But let's see if this is really
needed first.
I think what is proposed in that JBS issue should help in most of the
cases. i.e. the stacktrace probably won't be necessary. However, just to
make a note of it here - in the case of --illegal-access=debug the
stacktrace had helped decide if a particular call path can be bypassed
to get past the issue, instead of attaching some IDE debugger and
figuring out why the specific class/method was doing what it was doing.
As for which system property to use, I don't have any specific
preference. I think the existing one is fine too. One thing that might
need consideration is whether this would adversely impact applications
which have java.security.debug system property set to "all" and they now
start seeing these stacktraces of "sm" in the output.
-Jaikiran
