Hi Paul,
On 12/20/2016 02:51 AM, Paul Sandoz wrote:
Hi Peter,
Very good work (that’s one heck of a test on steroids).
Which would not be possible without such nice APIs like Stream with
lambdas and JavaCompiler... ;-)
Trivially on Class you could turn the “ Note that there may be …” into @apiNote.
Like this?
http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.09/
In PublicMethodsTest can you merge Case and Case1? or did you intend the
separation for future extensions?
Yes. While I can't currently imagine a situation that is not covered by
the test, I also can't prove that this is an exhaustive test. So if
someone discovers a situation that is important and not covered, it
would be easy to create new Case implementation to cover just this
situation and not have to touch Case1...
Maybe, if the need arises, the templating, generation of combinations
and compilation could even be factored out into a test utility and used
in some other test?
Regards, Peter
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
