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

[Jaikiran Pai]

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