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

[Peter Levart]

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