[Prateek]: Although, static methods cannot be overridden, you can hide them which would have been the case if you had not assigned weaker access privileges. The compiler is not required to enforce this. Not required to enforce what? The compiler
is required to prevent programmers from hiding a static method with another static method with weaker access. From
JLS 8.4.8.3: "The access modifier (�6.6) of an overriding or hiding method must provide at least as much access as the overridden or hidden method, or a compile-time error occurs." The compiler is behaving correctly according to the specification - except for the incorrect terminology.
[Aaron]: Static methods are not inherited. The SCJP authors makes this clear, the Java specification makes this clear. No, the Java specification does not agree with this statement. The term
inherited is defined in
JLS : "The members of a class type (�8.2) are classes (�8.5, �9.5), interfaces (�8.5, �9.5), fields (�8.3, �9.3, �10.7), and methods (�8.4, �9.4). Members are either declared in the type, or
inherited because they are accessible members of a superclass or superinterface which are neither private nor hidden nor overridden (�8.4.8)." The fact that they use italics for
inherited tells us this is the official definition according to the JLS - this is also the passage you find if you look up "inheritance - term definition" in the index. To be inherited, a member has to be accessible, and not overridden or hidden. There's no requirement that it be non-static. Further, the fact that they said "nor hidden" confirms that static members are being considered here, because the term hidden would
only apply to static members.
Various other books may use the term "inherited" differently; that's their prerogative. But that doesn't change the JLS definition.
[Ruben]: 3. I think that not only the compiler is outputting the wrong message, but that it is not allowing behavior that should be allowed. Obviously I agree with the first point. As for the second, the compiler is doing exactly what the JLS requires here, aside from its misleading language. However I would agree that the JLS could have, and perhaps should have, given a different rule for this. It would not necessarily create any problems to allow programmers to hide a static methods with a static method with weaker access. Or with a completely different return type, or a different throws clause. The two static methods are really unrelated, except for the rules given by the JLS, and the fact that they share the same name.
However, I think the main reason that the JLS regulates hiding they way they do is that doing so makes it easier for programmers to refactor by making a static method into an instance method (or vice versa). This is not an unusual thing to do, in my experience, and it would be harder if your static methods could have incompatible access, return types, and throws clauses. So I think it's not necessarily a bad thing that Java's designers chose these rules.
[Juva]: I think as long as the compiler is concerned , it checks for the overriding rules at first (neither cares its defined as static or non static ) Well, you seem to be ignoring the terminology used in the JLS here, the same way that the author of the compiler error message did. I think that will just create further confusion at this point. When you say "overriding", I can't really tell what you mean, because as I understand the term, it
only applies to non-static methods.