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

[Paul Sandoz]

Hi Peter,

Very good work (that’s one heck of a test on steroids).

Trivially on Class you could turn the “ Note that there may be …” into @apiNote.

In PublicMethodsTest can you merge Case and Case1? or did you intend the separation for future extensions?

Paul.

> On 19 Dec 2016, at 01:41, Peter Levart <peter.levart at gmail.com> 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
>>> 
>> 
>