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