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

[Jan Lahoda]

On Wed, 20 Nov 2024 12:57:25 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please correct me if I am wrong, but:
>> - reading JLS 8.4.8.1 and JLS 8.4.8.3, 8.4.8.1 defines the "overrides" relation between two methods, and this relation does not include return type, throw exception, and to some degree modifiers. These are additional conditions, but these are conditions like "if `m_C` overrides `m_A` (when viewed from `C`)", and <some> condition is met a compile-time error occurs. I.e. the fact that there e.g. an incorrect throws clause does not mean that `m_C` does not override `m_A` (when viewed from `C`), it only means a compile-time error occurs.
>> - the `Elements.overrides` method strives to implement the relation, not the additional checks.
>> 
>> I agree it is reasonable to include a warning that only the relation is checked, not the additional constraints. But I find the wording "has not been sufficiently compiled" fairly confusing. I would try to point out this method only implements the "overrides" relation, not the additional constraints that are not part of the relation as such, as defined in JLS 8.4.8.1 and JLS 8.4.8.3. And hence, the two methods may satisfy the "overrides" relation, but still be part of erroneous code.
>
>> 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.

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

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