On 27/06/2020 01:40, serguei.spit...@oracle.com wrote:
The implementation has this order of lookup:
// The agent class must have a premain or agentmain method that
// has 1 or 2 arguments. We check in the following order:
//
// 1) declared with a signature of (String, Instrumentation)
// 2) declared with a signature of (String)
// 3) inherited with a signature of (String, Instrumentation)
// 4) inherited with a signature of (String)
The declared methods are gotten with the getDeclaredMethod and
inherited with the getMethod.
This works for both 1-arg and 2-arg premain methods, so I'm not sure
what is inconsistent.
Or you have a concern there can be a non-nice NoSuchMethodException?
In fact, I don't understand why there is a need to use the
getDeclaredMethod.
As I see, the getMethod should return a declared method first, and
only if it is absent then it checks for a inherited one.
The JPLIS agent used getMethod when it was originally created in JDK 5
so it would only find public methods. I haven't studied the intervening
history too closely but I assume JDK-6289149 (in JDK 7) created the
inconsistency between the spec and implementation when it explored the
scenario of premain declared in a super class with different arity
and/or modifiers to the premain in the sub-class. I assume the tests
that you've been forced to change are related to this same issue.
So given where we are, and given the statement "The JVM first attempts
to invoke the following method on the agent class" in the spec then I
guess it's okay to keep the getDeclaredMethod to deal with "whacky" case
where a super class of the agent class has a public premain method.
-Alan.
