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
