RFR: 8365676: javac incorrectly allows calling interface static method via type variable [v2]

Chen Liang liach at openjdk.org
Wed Sep 10 19:14:12 UTC 2025


On Wed, 3 Sep 2025 21:07:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The interface static methods added in Java 8 are never inherited in method resolution. However, javac incorrectly allowed them to be resolved against type variables with an interface as its only upper bound, which violates JLS 4.9:
>> 
>>> The members of an intersection type are the members of the class or interface it induces.
>> 
>> Combined with JLS 4.4:
>> 
>>> The members of a type variable X with bound T & I1 & ... & In are the members of the intersection type ([§4.9](https://docs.oracle.com/javase/specs/jls/se24/html/jls-4.html#jls-4.9)) T & I1 & ... & In appearing at the point where the type variable is declared
>> 
>> Last time this piece of code in Attr was updated was around Java 7, so this was probably missed in Java 8.
>> 
>> The test cases added showcases wrong ways to refer to interface static methods: `Collator`, a subtype of `Comparator`, cannot use `reverseOrder`, so shouldn't type variable `T` bounded by `Comparator<Integer>` be able to do so.
>> 
>> In addition, the error for private member access on type variables should probably have been symbol not found instead of access errors - we might revisit that later. I made the new error symbol not found for parity with interface static reference on classes, as showcased in the compiler output in this new test.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Break up long conditional, add intersection bounded test case
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typevar-inherit-interface-static
>  - 8365676: javac incorrectly allows calling interface static method via type variable

Sure, we can always review the access error vs symbol not found message later. There has been a similar problem with hotspot runtime, where constructor lookup in java.lang.Class always result in an IllegalAccessError and never NoSuchMethodError. The present "access error" for private methods should be good to keep.

Thanks for the reviews! I will merge mainline and do another tier 1-3 before integration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27015#issuecomment-3276200303


More information about the compiler-dev mailing list