On Tue, 12 Jul 2022 22:33:47 GMT, Nir Lisker <nlis...@openjdk.org> wrote:
> 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. Eclipse user here. I have most of the name shadowing conflicts off, for precisely the reason that I should not have to care about whether or not something that is (package) private happens to coincide with a supertype or enclosing type. When writing a new (package) private method, trying to avoid a name that happens to be used in a super or enclosing type doesn't even come into play -- it is private for a reason. Not to mention that a new method added to the super or enclosing type might suddenly cause "warnings" for (package) private methods in a sub or nested type, which is ridiculous. Instead, use `@Override` always, and make it an error if it is missing. These compiler warning settings are more than likely just a left over from the days before `@Override` existed. ------------- PR: https://git.openjdk.org/jfx/pull/824
