RFR: 8062389, 8029459, 8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more

[joe darcy]

Hi Peter,

Revised specification looks good; thanks,

-Joe


On 12/19/2016 1:41 AM, Peter Levart wrote:
> Hi,
>
> This is the latest webrev of changes to Class.getMethod() and 
> Class.getMethods(), rebased to current tip of jdk9-dev, incorporating 
> comments from CCC review:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.08/
>
> Javadocs now include explicit text about Method(s) returned for 
> interface and array types as well as description of general algorithm. 
> Apart from javadocs, the following changed from webrev.07:
>
> - package-private Class.getMethdOrNull() (added by resent jigsaw 
> changes) must copy the returned Method object itself since 
> getMethod0() does not return a copy any more.
> - renamed PublicMethods[.MethodList].coalesce() -> merge(). I think 
> this is a less confusing name.
>
> For those of you, watching the public list, changes from webrev.04 
> that was last presented there are as follows:
>
> - PublicMethods class changed to embed, rather than extend a HashMap.
> -  Added a nearly-exhaustive test of Class.getMethods() and 
> Class.getMethod(): PublicMethodsTest. This is actually a test 
> generator. Given a Case template, it generates all variants of methods 
> for each of the types in the case. Case1 contains 4 interface method 
> variants ^ 3 interfaces * 4 class method variants ^ 3 classes = 4^6 = 
> 4096 different sub-cases of which only 1379 compile. The results of 
> those 1379 sub-cases are persisted in the Case1.results file. Running 
> the test compares the persisted results with actual result of 
> executing each sub-case. When running this test on plain JDK 9 
> (without patch), the test finds sub-cases where results differ:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/PublicMethodsTest.jtr
>
> Regards, Peter
>
>
> On 12/18/2016 06:01 AM, joe darcy wrote:
>>
>> Hello Peter,
>>
>> Some comments on the spec changes proposed in this request. The new 
>> algorithm looks, but I don't think it is appropriate to remove 
>> explicit text like
>>
>>> If this |Class| object represents an array type, then the returned 
>>> array has a |Method| object for each of the public methods inherited 
>>> by the array type from |Object|. It does not contain a |Method| 
>>> object for |clone()|.
>>>
>>> If this |Class| object represents an interface then the returned 
>>> array does not contain any implicitly declared methods from 
>>> |Object|. Therefore, if no methods are explicitly declared in this 
>>> interface or any of its superinterfaces then the returned array has 
>>> length 0. (Note that a |Class| object which represents a class 
>>> always has public methods, inherited from |Object|.)
>>>
>> even if it is (non-obviously) implied by the rest of the text.
>>
>> I'm voting to approve the request on the condition that some explicit 
>> discussion is added back to describe the handling of array types and 
>> interface.
>>
>> Sorry for the delays,
>>
>> -Joe
>>
>>
>> On 12/12/2016 11:09 PM, joe darcy wrote:
>>> Hi Peter,
>>>
>>> Sorry for the delays on reviewing your request. I've been backed up 
>>> on some ccc requests and I suspect the changes in your request are 
>>> subtle enough to merit some time to examine.
>>>
>>> I'm trying to clear out my queue this week ahead of the next round 
>>> of JDK 9 deadlines.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>>
>>> On 12/8/2016 12:42 AM, Alan Bateman wrote:
>>>> On 08/12/2016 08:34, Peter Levart wrote:
>>>>
>>>>> Hi Mandy, Alan,
>>>>>
>>>>> I know you're all very busy with finalization of jigsaw features 
>>>>> before the freeze, but I would like to ask whether there has been 
>>>>> any feedback on the CCC request for this issue.
>>>> Sorry for really really long delay on this. Joe Darcy is the chair 
>>>> of the CCC and is in his queue to review/approve. He told me 
>>>> yesterday that he wanted to get to it soon, I think he's just being 
>>>> pulled into too many issues at the moment. Joe, do you have an ETA 
>>>> for Peter? I think it's important that we get this into jdk9/dev by 
>>>> Dec 16 in order to make the Dec 22 promotion.
>>>>
>>>> -Alan
>>>
>>
>