RFR: 8281057: Fix doc references to overriding in JLS

[Pavel Rappo]

On Wed, 2 Feb 2022 14:37:39 GMT, Maurizio Cimadamore <mcimadamore at 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