
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

</head>

<body>

<div dir="ltr">

<div></div>

<div>

<div>Is it possible to redirect those vm messages with unified logging or vm-error files or similar command line flags to the launcher to keep stdout/stderr clean?</div>

<div dir="ltr"><br>

</div>

<div dir="ltr">Gruss</div>

<div dir="ltr">Bernd</div>

<div id="ms-outlook-mobile-signature">

<div style="direction: ltr">-- </div>

<div style="direction: ltr">http://bernd.eckenfels.net</div>

</div>

</div>

</div>

<hr style="display:inline-block;width:98%" tabindex="-1">

<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> security-dev <security-dev-retn@openjdk.java.net> im Auftrag von Sean Mullan <sean.mullan@oracle.com><br>

<b>Gesendet:</b> Monday, June 14, 2021 8:49:43 PM<br>

<b>An:</b> Jaikiran Pai <jai.forums2013@gmail.com>; security-dev@openjdk.java.net <security-dev@openjdk.java.net><br>

<b>Betreff:</b> Re: JDK 17 EA build 26 - Better debuggability of SecurityManager WARNING messages?</font>

<div> </div>

</div>

<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">

<div class="PlainText">We already are working on improvements to the warning message to show

<br>

the class and the source of the code calling System::setSecurityManager. <br>

See <a href="https://bugs.openjdk.java.net/browse/JDK-8268392">https://bugs.openjdk.java.net/browse/JDK-8268392</a><br>

<br>

If that is not sufficient and a stack trace is really still needed, my <br>

preference would be to leverage the existing java.security.debug system <br>

property, and add a new value, say "sm" and that would additionally <br>

print a stack trace. But let's see if this is really needed first.<br>

<br>

--Sean<br>

<br>

On 6/14/21 12:59 PM, Jaikiran Pai wrote:<br>

> While testing the Apache Ant project with the latest released EA of JDK<br>

> 17[1] (build 26), at least one of our internal test case has started<br>

> failing. The failure relates to the new "WARNING" message that gets<br>

> printed out to System.err when some code at runtime sets the security<br>

> manager. The test case we have expects that the System.err stream<br>

> contains only specific content. However, with this change, it now finds<br>

> the expected content plus this additional warning message:<br>

> <br>

> WARNING: java.lang.System::setSecurityManager is deprecated and will be<br>

> removed in a future release.<br>

> <br>

> Given the way the test is written, it doesn't like the presence of this<br>

> additional content on System.err and fails.<br>

> <br>

> "Fixing" this test itself is pretty trivial for us and given that it's<br>

> just one such test, I plan to just go ahead and do that tomorrow.<br>

> However, what I'm more interested in is what part of the code at runtime<br>

> is setting the security manager. I think even that part I can probably<br>

> easily narrow it down tomorrow once I look into the code. But from what<br>

> I imagine, this is going to be much more difficult to narrow down if the<br>

> security manager is being set at runtime from third party library code,<br>

> deep in the ecosystem of the deployed application (imagine some code<br>

> embedding Ant project and invoking it from their project).<br>

> <br>

> I understand that the -Djava.security.manager system property allows the<br>

> values "allow" and "disallow", but additionally would it be possible to<br>

> introduce a new (optional) system property which takes a value "debug"?<br>

> When this system property is set to "debug" and the Java runtime detects<br>

> that a WARNING needs to be issued because of runtime setting of security<br>

> manager, then a stacktrace is dumped showing the call location of each<br>

> such code which is setting the security manager? This would be similar<br>

> to the --illegal-access flag (although not a system property) that had<br>

> the "debug" option, which I thought proved to be very useful when<br>

> narrowing down the reflective access calls.<br>

> <br>

> <br>

> [1] <a href="https://jdk.java.net/17/">https://jdk.java.net/17/</a><br>

> <br>

> -Jaikiran<br>

> <br>

> <br>

</div>

</span></font></div>

</body>

</html>