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

[Mandy Chung]

On 6/27/20 12:23 AM, Alan Bateman wrote:
> 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.
>

Thanks for digging up the history.

> 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.
>

I also think it's okay to get a different exception message in this case.

Serguie - I reviewed this version.  It looks okay.
> New wevrev version is:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/instr-setAccessible.2/

Mandy



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20200629/250104e9/attachment-0001.htm>