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

Jan Lahoda jlahoda at openjdk.org
Wed Nov 20 07:36:15 UTC 2024


On Wed, 20 Nov 2024 05:58:35 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Please review this essentially doc only change.
>
> src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 790:
> 
>> 788:      * requirements might not be checked, potentially causing this method
>> 789:      * to return a false positive.
>> 790:      *
> 
> 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]".

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.

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

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


More information about the compiler-dev mailing list