15 RFR(XS): 8165276: Spec states that invoke the premain method in an agent class if it's public but implementation differs

[Alan Bateman]

On 27/06/2020 01:40, serguei.spitsyn at 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.