Community
Participate
Working Groups
With the "Method does not override a package visible method" warning on, I would expect the following piece of code to show a warning on Extend.method() definition: public class Base { private void method() {} } public class Extend extends Base { void method() {} }
This is item 13 of http://wheredatapp.com/blog/2015/11/19/why-intellij-idea-is-better-than-eclipse
(In reply to Mickael Istria from comment #0) > With the "Method does not override a package visible method" warning on, I > would expect the following piece of code to show a warning on > Extend.method() definition: Except that Base.method() is not package visible. => The label and semantics of the option would need to be *changed*. Generally, I'd say, this is what @Override is for. It faithfully reports every failed attempt to override, and also helps for documentation.
(In reply to Stephan Herrmann from comment #2) > Except that Base.method() is not package visible. > => The label and semantics of the option would need to be *changed*. Ok, so it would most likely be another check then? If so, I let you update the title to something more appropriate. > Generally, I'd say, this is what @Override is for. It faithfully reports > every failed attempt to override, and also helps for documentation. I agree that @Override is the best way to go. But IDEs are not only for good developers, so we can easily imagine some of Eclipse IDE users not using @Override where they should. Also, there is the case of a user overriding the parent private method by mistake: since the private method is not visible in the scope of their development, users can easily create a new method with same name and face potential issue later, if the method in parent becomes package-public or protected. That's why a warning could tell: "You're creating a method with same name as a private method already existing in class hierarchy. It's recommended to use a different name."
