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
