RFR: 8174840: Elements.overrides does not check the return type of the methods [v3]

[Pavel Rappo]

On Thu, 21 Nov 2024 12:23:39 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>>> The gist of this paragraph is good; some refinement is needed to not imply any particular requirements on the implementation, something like :"An implementation [of annotation processing] may choose to not check the additional requirements [under some limited conditions]".
>> 
>> I tried to rephrase it the way you seem to have proposed; is that better?
>
> My idea was something along these lines:
> 
>> This method implements the overrides relation as specified in JLS 8.4.8.1. It does not implement the additional compile-time checks that Java compilers follow, specified in JLS 8.4.8.1 and 8.4.8.3, in particular the additional constraints on thrown types, return types and those constrains on method modifiers not directly bound to the overriding relation as such.
> 
> As I understand now, there may be implementations that also do the additional checks, so if we that should be permitted, the it could say "may not", instead of "does not".
> 
> Not sure if this makes sense.

I hear you: the Java Language Specification separates "overrides" from those additional checks.

So, if `Elements.overrides` models "overrides", it is under no obligation to perform those checks. Moreover, I think, it might not be always possible to perform them. Still, I believe we should __NOT__ say that this method always skips them. So your "may not" is better.

Here's why. Whether any additional checks are performed seems to be implementation-dependant. For example, here's how ECJ (Eclipse) runs that same test (after some necessary modifications to decouple the test from our test infrastructure):


% java -jar ecj-4.33.jar --release 22 -classpath . -processor TestOverrides -proc:only S.java
1. ERROR: protected void m()  does not override public void m()  from T1
2. ERROR: void m()  does not override public void m()  from T2
3. ERROR: private void m()  does not override public void m()  from T3
3 problems (3 errors)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22244#discussion_r1852170806