Bug 65381 - java task without fork=yes shows "WARNING: java.lang.System::setSecurityManager is deprecated and will be removed in a future release...." with jd17ea26
Summary: java task without fork=yes shows "WARNING: java.lang.System::setSecurityManag...
Status: NEW
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.10.9
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Ant Notifications List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-06-15 13:20 UTC by Stefan Huehner
Modified: 2021-06-17 17:02 UTC (History)
0 users



Attachments
bug reproducer - part1 (593 bytes, text/xml)
2021-06-15 13:24 UTC, Stefan Huehner
Details
bug reproducer - part2 (100 bytes, text/x-java)
2021-06-15 13:24 UTC, Stefan Huehner
Details
output with the bad/unexpected behavior (331 bytes, text/plain)
2021-06-15 13:28 UTC, Stefan Huehner
Details
good/expected output (106 bytes, text/plain)
2021-06-15 13:29 UTC, Stefan Huehner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Huehner 2021-06-15 13:20:56 UTC
Latest JDK17 early-access build integrated the following change:

https://openjdk.java.net/jeps/411

That deprecated the java security managing with the option for removal.

Having an build.xml file calling the <java> task without using fork=yes seems to trigger that warning at runtime

Apart from that being something to be fixed eventually it created extra problems when output of said '<java>' tasked is put into an outputProperty as then the extra text in that property breaks further processing.

Adding fork=yes to the <java> task target does avoid triggering the problem

Note that JDK17 is likely the next LTS java version
Comment 1 Stefan Huehner 2021-06-15 13:24:20 UTC
Created attachment 37897 [details]
bug reproducer - part1
Comment 2 Stefan Huehner 2021-06-15 13:24:35 UTC
Created attachment 37898 [details]
bug reproducer - part2
Comment 3 Stefan Huehner 2021-06-15 13:25:58 UTC
Attached a quick reproducer to show the behavior.

Usage:
point JAVA_HOME to jdk17ea26 build (or higher)

ant -f demo.xml bad

Show the unexpected warning inside the ${output} property.

ant -f demo.xml good

Does show the expected output.
Only change in 'good' target is using fork=yes to avoid triggering the unexpected behavior.
Comment 4 Stefan Huehner 2021-06-15 13:28:49 UTC
Created attachment 37899 [details]
output with the bad/unexpected behavior
Comment 5 Stefan Huehner 2021-06-15 13:29:05 UTC
Created attachment 37900 [details]
good/expected output
Comment 6 Jaikiran Pai 2021-06-17 17:02:07 UTC
Hello Stefan,

Thank you for reporting this issue. We have been aware of this change that the upcoming JDK 17 release is proposing and have noticed this WARNING message which impacts the STDERR stream content of an application. One of our internal test case in the Ant project when run against this EA version, runs into this same issue that you describe here.

This has been brought to the notice of the JDK dev team not just by us but by all other impacted projects. Most of those discussions can be viewed in the JDK security-dev mailing list discussions https://mail.openjdk.java.net/pipermail/security-dev/2021-June/thread.html. From my understanding this WARNING message is here to stay, so we (the Ant project) will have to check our usage of SecurityManager internally in the project and come up with a plan on how we deal with it in future (note that JDK 17 only deprecates the SecurityManager for future removal and except for the WARNING message in the STDERR nothing else changes in JDK 17, functionality wise).

Now coming to the example you posted, if the output of your program on STDOUT is being impacted (which is what that example is demonstrating) then it's a simple fix that needs to be done to your build file. Right now, your build file looks like:

<java classname="Demo" outputproperty="output" classpath="."/>

As per the documentation of this task[1], the outputproperty documentation reads:

>> The name of a property in which the output of the command should be stored. Unless the error stream is redirected to a separate file or stream, this property will include the error output.

So in its current form the "output" property value will include even contents from STDERR (which is where that WARNING message is being logged). To fix this and just get back your output from STDOUT of the program, you can either set an additional "errorproperty" attribute or set the "discardError" attribute (which is introduced in recently released 1.10.10 version of Ant) to "true". Once you do that, your "bad" target should start seeing only the value "42" in the output property value, just like you see in the "good" target.



[1] https://ant.apache.org/manual/Tasks/java.html