RFR: 8062389, 8029459, 8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more

Alan Bateman Alan.Bateman at oracle.com
Fri Oct 14 12:16:38 UTC 2016

On 13/10/2016 18:30, Peter Levart wrote:

> Hi Paul, Alan,
> I incorporated Paul's suggestions into new webrev:
> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.05/
> This iteration also contains a nearly-exhaustive test of 
> Class.getMethods(): PublicMethodsTest. It 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 218 sub-cases where results differ:
> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/PublicMethodsTest.jtr
> Looking at those differences gives the impression of the effects of 
> the patch.
Overall I think this looks very good. I mostly focused on the 
PublicMethods implementation to satisfy myself that it does selects the 
most specific methods. In passing I wonder if "combine" or "merge" might 
be better than "consolidate" for method name and terminology, a minor 
point of course.

Given the behavior change then I think we'll need to capture it in a 
release notes. I can't think of any libraries or frameworks that might 
have see but something might come out of the woodwork and would be nice 
to be able to point to a summary.

I assume that copyright headers will be added before this is pushed. 
Also there is a @SuppressWarnings arguments that I don't recognize (IDE 
specific)? It would good to trim back some of the really long times in 
the test too (there are some >150 char lines that will be a pain to 
review side-by-side when there are future changes).


More information about the core-libs-dev mailing list