On Fri, 8 Jul 2022 21:37:47 GMT, Andy Goryachev <d...@openjdk.org> wrote:
> The fix includes: > - renaming of offending methods to avoid confusion > - explicitly declaring the offending methods as private I've finished an analysis of a few of the cases here. After checking the [JLS](https://docs.oracle.com/javase/specs/jls/se18/html/jls-9.html#jls-9.6.4.4), in my opinion this warning should be turned off without "fixing" its occurrences for the following reason: If a method in a supertype is not visible to a subtype, then it is an implementation detail. Subtypes should not be concerned with the names of methods outside of their visibility (whether in the hierarchy or not). If a method is supposed to override another method, then the `@Override` annotation should be used. This will give the definitiveness of overriding - if the method really is overriding, nothing else is needed; if it isn't, a compiler error occurs. Therefore, my recommendation is to fix all "method x is overriding method y but does not have the `@Override` annotation" warnings (I have my Eclipse set to treat missing override annotations as an error even, and it has served me well). Once all overriding methods are annotated and all non-overriding methods are not annotated, this warning becomes meaningless. One interesting case is the one I mentioned with `D3DGraphics#getContext`: it really does override the superinterfce method, but also has the same signature of a method in `BaseShaderGraphics`, resulting in a "fake override", but the `@Override` annotation is still applicable. If we turn off the "fake override" warning, everything remains clear because the IDE tells us which method is really being overridden. In fact, this warning just made this case more confusing because it implies an override that doesn't happen, and hides the one that really does. ------------- PR: https://git.openjdk.org/jfx/pull/824
