On Wed, 2 Feb 2022 14:37:39 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org> wrote:
>> My guess is that "transitivity" here refers to the subclass relationship >> being the transitive closure of the direct subclass relationship. Could it >> also be that the "quirk" paragraph starting at >> com/sun/tools/javac/code/Symbol.java:2057 is relevant here? @mcimadamore? > > First, this class contains many references to 8.4.6.x - which should really > be 8.4.8.x - not just this one. > > I'm not 100% sure about the "without transitivity" comment, but if I had to > guess I'd say that it refers to the fact that the checks described in 8.4.8.3 > are missing from this routine. More specifically, this section: > > > It is a compile-time error if a class or interface C has a member method m1 > and there exists a method m2 declared in C or a superclass or superinterface > of C, A, such that all of the following are true: > * m1 and m2 have the same name. > * m2 is accessible (§6.6) from C. > * The signature of m1 is not a subsignature (§8.4.2) of the signature of m2 > as a member of the supertype of C that names A. > * The declared signature of m1 or some method m1 overrides (directly or > indirectly) has the same erasure as the declared signature of m2 or some > method m2 overrides (directly or indirectly). <---------- > > As you can see, the last bullet introduces some sort of global requirement > across the inheritance chain; this constraint was necessary after Java 5, as > generics require the introduction of bridge methods, and it is possible, in > some extreme cases, for a subclass to override (accidentally) a bridge > method. The JLS doesn't say the word "bridge method" anywhere, but this is > what this check morally does. > > Now, in an early version of the Java compiler (5 and 6, IIRC), we used to > check for clashes with bridge methods at code generation time. So, the checks > in the compiler frontend, such as Symbol::overrides did not really have to > concerb with that expensive side of the override check. > > But, as the implementation matured, it became clearer that (a) the > code-generation clash check was not enough to detect all problematic cases > and (b) detecting clashes at code generation time was *too late*, especially > for clients of the compiler API which might only run the "analyze" step. For > these reasons, staring from Java 7, the frontend also has a more expensive > check which supports 8.4.8.3 in full (Check::checkOverrideClashes). > > Of course, not being the author of that comment, this is only my best guess > as to what that could mean :-) FWIW, I found a related bug: https://bugs.openjdk.java.net/browse/JDK-4362349. It might be responsible for that "(without transitivity)" caveat. ------------- PR: https://git.openjdk.java.net/jdk/pull/7311
