Hello Max,
On 30/06/21 2:42 am, Wei-Jun Wang wrote:
On Jun 29, 2021, at 3:08 AM, Jaikiran Pai <jai.forums2...@gmail.com> wrote:
On 29/06/21 12:34 pm, Jaikiran Pai wrote:
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.
To be clear, just once for each caller class.
In your case, is the class always the same object? I was thinking about if I should
use a String or a Class<?> as the map key. Is it possible for the same class to
be loaded again and again?
In the case we are dealing with, the class is always
"org.apache.tools.ant.types.Permissions". It will always be loaded by
one single classloader (so classloaded just once). However, multiple
different instances of this class will get created during the lifetime
of the build and each such instance of
org.apache.tools.ant.types.Permissions can/will invoke this
setSecurityManager method.
One additional detail - this org.apache.tools.ant.types.Permissions is
_not_ final, which means it can potentially have sub-classes. In the
context of Ant, the fact that this class is not final shouldn't really
have any implication in how the caching in java.lang.System gets
implemented. I only bring this up here because maybe it has to be taken
into account for the general cases? I haven't yet checked how the
Reflection.getCallerClass() is implemented in the JDK and whether this
caching logic that's being introduced needs to take into account
sub-classes while deciding whether or not to issue a warning.
-Jaikiran
