On 29/06/21 12:21 am, Alan Bateman wrote:
On 28/06/2021 18:16, Jaikiran Pai wrote:
On a slightly related note, I was wondering why we decided to go with
what appears to be a bit more aggressive approach to these warning
messages as compared to what was done with the illegal reflective
access warnings? I would have thought that the illegal reflective
access changes would be much more involved if not the same level as
moving away from setSecurityManager calls.
The typical SM setup will be to set it once, the Ant "same JVM"
scenario where it sets and then resets it may be unusual.
In any case, the original implementation patch did have caching to
avoid duplicates. It wasn't quite right and had to be pulled, it may
be time to re-visit that to avoid too much noise for code that sets it
many times.
Thank you Alan. I see that
https://bugs.openjdk.java.net/browse/JDK-8269543 has been created for
this. I'll keep a watch on that one.
> Out of all these 4 points, I think if point number 2 can be addressed
such that it just prints only once the warning for each caller class,
then the issue noted by users of Ant build file will be drastically
reduced. I haven't yet tried or proved it, but I think we will end up
with just one log message in their STDERR for the entire build for a
majority of the cases. I will experiment with that this week to see if
that's true.
FWIW - I implemented a very primitive cache in the System class to log
this message just once and see if it helps for the general/regular
usecase that I used as an example. That indeed helped and I see that the
warning message just gets printed once for the entire lifetime of the
build process, no matter how many "java" tasks get called. So the
changes in JDK-8269543 will help us to a considerable extent.
-Jaikiran
