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