RFR: 8062389, 8029459, 8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more
Paul Sandoz
paul.sandoz at oracle.com
Wed Dec 21 00:12:07 UTC 2016
> On 20 Dec 2016, at 00:56, Peter Levart <peter.levart at gmail.com> wrote:
>
> 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/
>
Yes.
>>
>> 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…
>
Ok.
> 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?
>
Yes.
+1
Paul.
More information about the core-libs-dev
mailing list