RFR: JDK-8210197: candidate selection during overload resolution can lead to unexpected results for diamond expressions (original) (raw)

Vicente Romero vicente.romero at oracle.com
Wed Nov 7 01:45:15 UTC 2018

Hi,

Please review patch for [1] at [2]. The issue was can be explained with these two simple classes:

package pkg1;

public class MyClass {     protected MyClass() {}                // (i)     protected MyClass(String s) {}    // (ii) }

package pkg2;

import pkg1.*;

class Client {     void foo(MyClass m) {}

    void bar() {         foo(new MyClass<>(){});     } }

both constructors are protected and given that we are dealing with a diamond expression, speculative attribution is used. During speculative attribution, javac removes the class definition from the equation meaning that: new MyClass<>(){} is rewritten as: new MyClass<>()

the first expression has access to the protected constructors, the other one not.  So as both are protected, they are considered not accessible during overload resolution. Still constructor (i) is applicable but constructor (ii) is not applicable. So my proposal is to create an access error at Resolve::selectBest also for this case. Right now an access error is created only if no other method is found. When an access error is returned during overload resolution, the inaccessible symbol is still used and attached to the AST till the check phase can double check and issue an error or not. As during the check phase the diamond expression is attributed without rewriting, the compiler can then find out that constructor (i) is both applicable and accessible.

Thanks, Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8210197 [2] http://cr.openjdk.java.net/~vromero/8210197/webrev.00/

More information about the compiler-dev mailing list