On Fri, 12 Sep 2025 12:18:00 GMT, Maurizio Cimadamore <[email protected]> wrote:
>> Recent fix for [JDK-8359370](https://bugs.openjdk.org/browse/JDK-8359370) >> introduced a minor bug. This code should be accepted by javac: >> >> class SuperClass<T> { >> public SuperClass(Object o) {} >> } >> >> class Sub<T> extends SuperClass<T> { >> public Sub() { >> super(new Object() { >> void foo() { >> getClass(); >> } >> }); >> } >> } >> >> >> but it is currently rejected as the `getClass` invocation is considered to >> be an invocation of an instance method of class `Sub` > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1478: > >> 1476: return TreeInfo.isExplicitThisReference(types, >> (ClassType)env.enclClass.type, fa.selected); >> 1477: } >> 1478: if (currentClassSym != env.enclClass.sym) { > > stylistic (and optional). In a way, if we added that as part of an `else if` > it would make it clear that we're in an "implicit" qualifier case (e.g. > simple name). Also, maybe adding a one line comment about why we're doing the > extra check might be helpful for future reference. Question: can we ever get here for a static symbol? I think for statics we should never run `analyzeSymbol` right? I'm not sure: `analyzeSymbol` seems called regardless of static-ness. Then it has two checks inside, one for writes and another for reads. The check for reads excludes `static` symbols, but the check for writes doesn't? I think we should maybe write some tests where we assign to a static field from a prologue :-) ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1567#discussion_r2344077216
