RFR: 8062389, 8029459, 8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more
joe.darcy at oracle.com
Mon Dec 19 15:25:05 UTC 2016
Revised specification looks good; thanks,
On 12/19/2016 1:41 AM, Peter Levart wrote:
> 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:
> 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:
> 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
>> Sorry for the delays,
>> 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.
>>> 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.
More information about the core-libs-dev