Community
Participate
Working Groups
public class TestExtractSuperclass { static void staticMethod() {} void instanceMethod() { TestExtractSuperclass.staticMethod(); } } Highlight some of it and choose extract superclass. Tick both methods. You get : public class Superclass { static void staticMethod() {} public Superclass() { super(); } void instanceMethod() { TestExtractSuperclass.staticMethod(); } } The line TestExtractSuperclass.staticMethod(); results in a compilation error The static access modifier should be removed (btw it is redundant in the first place - is there a warning for it ?)
> The line TestExtractSuperclass.staticMethod(); results in a compilation error To get the compilation error, have you set the Compiler Errors/Warnings preference for "Indirect access to static member" as Error? If it is set to "Ignore", we do not get any compile error. In the example, the resulting code after extract superclass refactoring (with old static member qualifier in the superclass) would be incorrect if we add a new static member to the subclass that hides the one in superclass, as now the qualified access would refer to the new static member. Hence, the static member qualifiers should be removed while performing the extract superclass refactoring. > (btw it is redundant in the first place - is there a warning for it ?) There is no warning for the direct access to a static member.
(In reply to Noopur Gupta from comment #1) > > The line TestExtractSuperclass.staticMethod(); results in a compilation error > To get the compilation error, have you set the Compiler Errors/Warnings > preference for "Indirect access to static member" as Error? If it is set to > "Ignore", we do not get any compile error. Yes I did - but I also use the extract superclass to achieve Extract class - and when I break the inheritance chain between the classes it is then truly an error :) > In the example, the resulting code after extract superclass refactoring > (with old static member qualifier in the superclass) would be incorrect if > we add a new static member to the subclass that hides the one in superclass, > as now the qualified access would refer to the new static member. > Hence, the static member qualifiers should be removed while performing the > extract superclass refactoring. > Exactly ! > > (btw it is redundant in the first place - is there a warning for it ?) > There is no warning for the direct access to a static member. Added a request : https://bugs.eclipse.org/bugs/show_bug.cgi?id=422001 Added as a code cleanup request but a compiler warning would be better (more efficient) - what you say ? Thanks !
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
