Static method access dilemma and proposal: @NotInherited

Zhong Yu zhong.j.yu at gmail.com
Thu Jun 27 14:22:48 PDT 2013


On Thu, Jun 27, 2013 at 4:17 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
> Stephen, would it be more accurate to say that what you want is
> actually non-"overridable". It's not a problem that B inherits foo()
> from A. It is a problem that B may introduce its own foo(), therefore
> the meaning of `B.foo()` is a little uncertain.
>
> Non-overridable can be achieved by "final" on instance methods.
>
> For static methods, oddly enough, "final" has the same effect - it
> prevents subclass to introduce a method with the same signature -
>
> http://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.3.3
>
> It is a compile-time error to attempt to override or hide a final method.
>
> http://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.8.2
>
> If a class declares a static method m, then the declaration m is said
> to hide any method m', where the signature of m is a subsignature
> (§8.4.2) of the signature of m', in the superclasses and
> superinterfaces of the class that would otherwise be accessible to
> code in the class.
>
> Therefore if we have
>
>     class A
>
>         final static void foo(){}
>
>     class B
>
>         static void foo(){}
>
> B should not compile. (Unfortunately, it does compile in javac 7. A bug?)


Sorry, the example should say

    class B extends A

and it indeed does not compile in javac 7, hurray -

    error: foo() in B cannot override foo() in A, overridden method is
static,final




>
> So can we say "final" static method already does what you want to achieve?
>
>
> Zhong Yu


More information about the lambda-dev mailing list