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 turned on errors on missing `@Override` annotations. I got over 1k > > errors. I think it's worth fixing it in batches. > > missing @OverRide is a different warning. people do tend not to use this > annotation, so any legacy code base usually contains lots of those. same with > synthetic accessors and unused imports. You perhaps mean that old code bases may have many places where this is not done, but new code written by professional developers without `@Override` seems highly suspect as it is a very valuable annotation, especially during refactors and method renames -- the IDE will warn you if for some reason a method is declared overridden but doesn't override anything, very handy when an overridden method was renamed and you forgot one of its subclasses where it was overridden. Unused imports, just reorganize them one time project wide (same for `@Override`, it's a safe change). Synthetic accessors, aside from making call stacks a little uglier, they don't really need attention at all (they're not a performance issue in modern JVM's). > I am ok with fixing all warnings, but people who use other IDEs or the IDEs > with these warnings suppressed are bound to introduce them again and again. Missing overrides should be signaled in code reviews and/or automated. All IDE's support this and so they should just be configured properly. In my experience, I haven't seen code with missing `@Override`s unless the code base is incredibly old -- I'm a warning fixer myself, and I prefer to keep the warning list empty, so I would certainly have noticed this. Making JavaFX warning free would be a very good step, especially since some of the warnings can actually point to real issues. Eclipse makes such missing annotations (or other dubious constructs) painfully obvious with its clear and direct list of errors and warnings project wide. IntelliJ makes this a lot harder and is often (in my experience) a "source" of new warnings because people are not made aware of them explicitly enough. That is however no excuse for allowing such warnings to accumulate in the code base. ------------- PR: https://git.openjdk.org/jfx/pull/824
