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