Few reasons: static method must have a body even if they are part of abstract class because one doesn't need to create instance of a class to access its static method. Another way to think about it is if for a moment we assume it is allowed then the problem is that static method calls don't provide any Run Time Type Information (RTTI), remember no instance creation is required, thus they can't redirected to their specific overriden implementations and thus allowing abstarct static makes no sense at all. In other words, it couldn't provides any polymorphism benefit thus not allowed.
– sactiwNov 10 '16 at 16:18

5

If you have something to answer the question, post it as an answer, not a comment
– Solomon UckoNov 23 '16 at 22:58

A more concise answer would be 'bad language design.' Static should mean 'belongs to the class' because that's how it's used intuitively as this very question demonstrates. See "classmethod" in Python.
– Alexander LjungbergMay 15 '10 at 1:01

12

@Tomalak I apologize, I was not clear. Of course a static method 'belongs to the class'. Still, it is only in the sense that it lives in the same namespace. A static method is not a method of the class object itself: it does not operate with 'this' as the class object, and it does not participate properly in the chain of inheritance. If it truly was a class method abstract static would make perfect sense. It'd be a method of the class object itself which subclass objects must implement. Of course, the way things stands your answer is correct despite my griping about the language.
– Alexander LjungbergMay 15 '10 at 22:09

632

It's not a logical contradiction, it's a language shortcoming, multiple other languages support this notion. "abstract" mean "implemented in subclasses", "static" means "executed on the class rather than class instances" There is no logical contradiction.
– Eric GrangeJun 8 '10 at 9:04

10

@Eric: And still, what you say does not apply to abstract static: A function X that is "implemented in the subclass" cannot at the same time be "executed on the class" - only on the subclass. Where it then is not abstract anymore.
– TomalakJun 8 '10 at 11:21

68

@Tomakak: Your logic is circular. static doesn't mean "not empty" -- that's just a consequence of Java not allowing static methods to be abstract. It means "callable on the class." (It should mean "callable only on the class" but that's another issue.) If Java supported abstract static methods I'd expect it to mean that the method 1) must be implemented by subclasses, and 2) is a class method of the subclass. Some methods just don't make sense as instance methods. Unfortunately Java doesn't let you specify that when creating an abstract base class (or an interface).
– Michael CarmanMar 29 '11 at 20:10

Poor language design. It would be much more effective to call directly a static abstract method than creating an instance just for using that abstract method. Especially true when using an abstract class as a workaround for enum inability to extend, which is another poor design example. Hope they solve those limitations in a next release.

Java is full of strange limitations. Closures accessing only final variables is another. And the remaining list is almost endless. It is the job of a Java programmer to know them and their workarounds. In order to have fun we have to use something better than Java in our spare time. But I would not bother about. That is the seed to achieve progress.
– cevingDec 4 '12 at 18:48

19

I believe that what you refer to as "Poor language design" is really more of a "Protective language design", which purpose is to limit the OO principle violations that programers do due to unnecessary language features.
– eitanfarMar 25 '14 at 7:10

18

Is the concept of "abstract static" a violation of OO principles?
– TrevorMay 21 '14 at 21:38

6

@threed, Not at all, but of course there are folks who say that the mere concept of static itself is already a violation....
– PacerierSep 10 '14 at 18:26

3

The need for static is a clear demonstration that "OO principles" are not as all-encompassing as usually claimed.
– BenMay 12 '15 at 4:29

You can't override a static method, so making it abstract would be meaningless. Moreover, a static method in an abstract class would belong to that class, and not the overriding class, so couldn't be used anyway.

Yes it is really a shame by the way that static methods cannot be overridden in Java.
– MichelDec 16 '08 at 11:29

11

@Michel: what would be the point? If you want instance based behavior, use instance methods.
– Ran BironDec 16 '08 at 12:12

8

This answer is incorrect. Static methods in abstract classes work fine and are commonly used. It's just that a static methods of the class itself may not be abstract. @Michel it doesn't make sense to override a static method. Without an instance, how would the runtime know which method to invoke?
– ericksonDec 16 '08 at 15:57

61

@erickson - Even without an instance, the class hierarchy is intact - inheritance on static methods can work just like inheritance of instance methods. Smalltalk does it, and it is quite useful.
– JaredJan 20 '09 at 22:51

The abstract annotation to a method indicates that the method MUST be overriden in a subclass.

In Java, a static member (method or field) cannot be overridden by subclasses (this is not necessarily true in other object oriented languages, see SmallTalk.) A static member may be hidden, but that is fundamentally different than overridden.

Since static members cannot be overriden in a subclass, the abstract annotation cannot be applied to them.

As an aside - other languages do support static inheritance, just like instance inheritance. From a syntax perspective, those languages usually require the class name to be included in the statement. For example, in Java, assuming you are writing code in ClassA, these are equivalent statements (if methodA() is a static method, and there is no instance method with the same signature):

ClassA.methodA();

and

methodA();

In SmallTalk, the class name is not optional, so the syntax is (note that SmallTalk does not use the . to separate the "subject" and the "verb", but instead uses it as the statemend terminator):

ClassA methodA.

Because the class name is always required, the correct "version" of the method can always be determined by traversing the class hierarchy. For what it's worth, I do occasionally miss static inheritance, and was bitten by the lack of static inheritance in Java when I first started with it. Additionally, SmallTalk is duck-typed (and thus doesn't support program-by-contract.) Thus, it has no abstract modifier for class members.

"A static member cannot be overridden by subclasses" is wrong. It is possible, at least in Java6. Not sure since when it is the case.
– Steven De GrooteJul 5 '12 at 15:22

14

@Steven De Groote A static member indeed cannot be overridden by subclasses. If a subclass has a static method with the same signature as a static method in the superclass, it doesn't override it, it hides it. http://docs.oracle.com/javase/tutorial/java/IandI/override.html The difference is that polymorphism works only for overridden, but not for hidden methods.
– John29Dec 7 '13 at 14:24

1

@John29 Thanks for the clarification, but apart from the naming difference it seems similar in usage.
– Steven De GrooteDec 9 '13 at 8:09

2

@Steven De Groote Yes, it's similar in usage, but the behavior is different. That's the reason why there're no static abstract methods - what's the point of static abstract methods if they don't support polymorphism?
– John29Dec 10 '13 at 17:52

3

@Steven De Groote: The difference becomes apparent when you have a call to that method in the superclass itself. Suppose Super.foo calls Super.bar. If a subclass implements Subclass.bar, and then calls foo, then foo will still call Super.bar, not Subclass.bar. Hence, what you really have is two entirely different and unrelated methods both called "bar". This is not overriding in any useful sense.
– DoradusSep 2 '14 at 0:10

-1, It is not true that "Java does not allow static method to be overridden because static members and methods are compile time elements". Static type-checking is definitely possible with abstract static see stackoverflow.com/questions/370962/… . The real reason why Java does not allow static methods to be overridden is because Java does not allow static methods to be overridden.
– PacerierSep 10 '14 at 18:39

Overloading has nothing to do with polymorphism. Overloading and overriding have nothing in common except the prefix "over" in much the same way Java and JavaScript happen to both have "Java" in them. A method's name isn't what identities it, it's its signature that does. so foo(String) is not the same as foo(Integer) -- that's all it is.
– Captain ManDec 15 '16 at 20:15

@CaptainMan Overloading is literally called "parametric polymorphism" because, depending on the type of the parameter, a different method gets called which is polymorphism.
– DavorJan 28 '18 at 15:52

I didn't understand where you have provided an example of an abstract static method as asked in the question and you have written in bold CAN BE DONE IN JAVA. This is completely misguiding.
– BlipJun 28 '17 at 8:13

It doesn't per se allow you to define it as abstract static, but you can achieve a similar result whereby you can change the implementation of s static method using this pattern/hack. It's hardly misguided. It can be done, but using different semantics.
– momomoJun 28 '17 at 11:59

This is an example of extending an abstract class, then putting the static methods in the child. This is not an example of CAN BE DONE IN JAVA, in any way whatsoever.
– Scuba SteveFeb 2 at 1:08

@ScubaSteve First, you are wrong on your conclusion. Second, it achieves the same result. Meaning static access to a class can be changed by another implementation. It's not an answer as to saying I made the static keyword abstractable, but using this pattern you can could use static methods and still change their implementation. It does have the negative affect of being global only though, but for a test / prod / dev environment it does the trick for us.
– momomoFeb 3 at 18:13

An abstract method is defined only so that it can be overridden in a subclass. However, static methods can not be overridden. Therefore, it is a compile-time error to have an abstract, static method.

Now the next question is why static methods can not be overridden??

It's because static methods belongs to a particular class and not to its instance. If you try to override a static method you will not get any compilation or runtime error but compiler would just hide the static method of superclass.

I see that there are a god-zillion answers already but I don't see any practical solutions. Of course this is a real problem and there is no good reason for excluding this syntax in Java. Since the original question lacks a context where this may be need, I provide both a context and a solution:

Suppose you have a static method in a bunch of classes that are identical. These methods call a static method that is class specific:

Since in your final solution abstract class C doesn't has any static methods then why not just let C1 and C2 extend it and override doMoreWork() method and let any other classes make its instance and call required methods. Basically you are doing the same i.e. extending class C using anonymous class and then in C1 and C2 using its static instance to allow access from within a static method but this is not required at all.
– sactiwNov 10 '16 at 16:06

I don't understand the context that you have provided here. In your final solution what you can do is call C1.doWork() or C2.doWork() But you cannot call C.doWork(). Also in the example that you have provided, which won't work, suppose if it was allowed, then how will class C find the implementation of doMoreWork()? Finally I would call your context code a bad design. Why? simply because you have created a separate function for the code that is unique instead of creating a function for the code that is common and then implementing a static function in the class C. This is easier!!!
– BlipJun 28 '17 at 9:07

This means that any instance of Parent must specify how run() is executed.

However, assume now that Parent is not abstract.

class Parent {
static void run() {}
}

This means that Parent.run() will execute the static method.

The definition of an abstract method is "A method that is declared but not implemented", which means it doesn't return anything itself.

The definition of a static method is "A method that returns the same value for the same parameters regardless of the instance on which it is called".

An abstract method's return value will change as the instance changes. A static method will not. A static abstract method is pretty much a method where the return value is constant, but does not return anything. This is a logical contradiction.

Also, there is really not much of a reason for a static abstract method.

An abstract class cannot have a static method because abstraction is done to achieve DYNAMIC BINDING while static methods are statically binded to their functionality.A static method means
behavior not dependent on an instance variable, so no instance/object
is required.Just the class.Static methods belongs to class and not object.
They are stored in a memory area known as PERMGEN from where it is shared with every object.
Methods in abstract class are dynamically binded to their functionality.

A static method, by definition, doesn't need to know this. Thus, it cannot be a virtual method (that is overloaded according to dynamic subclass information available through this); instead, a static method overload is solely based on info available at compile time (this means: once you refer a static method of superclass, you call namely the superclass method, but never a subclass method).

According to this, abstract static methods would be quite useless because you will never have its reference substituted by some defined body.

And an abstract static method could be called without an instance, but it would require an implementation to be created in the child class. It's not exactly polymorphism, but the only way to get around it is to have the concrete child implement an interface that "requires" the "abstract static" method. Messy, but workable.
– fijiaaronNov 25 '10 at 2:11

3

actually, I was wrong. You can't have static methods in an interface either. Language flaw.
– fijiaaronNov 25 '10 at 2:17

I believe I have found the answer to this question, in the form of why an interface's methods (which work like abstract methods in a parent class) can't be static. Here is the full answer (not mine)

Basically static methods can be bound at compile time, since to call them you need to specify a class. This is different than instance methods, for which the class of the reference from which you're calling the method may be unknown at compile time (thus which code block is called can only be determined at runtime).

If you're calling a static method, you already know the class where it's implemented, or any direct subclasses of it. If you define

Then any Foo.bar(); call is obviously illegal, and you will always use Foo2.bar();.

With this in mind, the only purpose of a static abstract method would be to enforce subclasses to implement such a method. You might initially think this is VERY wrong, but if you have a generic type parameter <E extends MySuperClass> it would be nice to guarantee via interface that E can .doSomething(). Keep in mind that due to type erasure generics only exist at compile time.

So, would it be useful? Yes, and maybe that is why Java 8 is allowing static methods in interfaces (though only with a default implementation). Why not abstract static methods with a default implementation in classes? Simply because an abstract method with a default implementation is actually a concrete method.

Why not abstract/interface static methods with no default implementation? Apparently, merely because of the way Java identifies which code block it has to execute (first part of my answer).

Because abstract class is an OOPS concept and static members are not the part of OOPS....
Now the thing is we can declare static complete methods in interface and we can execute interface by declaring main method inside an interface

The idea of having an abstract static method would be that you can't use that particular abstract class directly for that method, but only the first derivative would be allowed to implement that static method (or for generics: the actual class of the generic you use).

That way, you could create for example a sortableObject abstract class or even interface
with (auto-)abstract static methods, which defines the parameters of sort options:

that can retrieve the types, build a pop-up menu to select a type to sort on and resort the list by getting the data from that type, as well as hainv an add function that, when a sort type has been selected, can auto-sort new items in.
Note that the instance of SortableList can directly access the static method of "T":

String [] MenuItems = T.getSortableTypes();

The problem with having to use an instance is that the SortableList may not have items yet, but already need to provide the preferred sorting.

Every method in an abstract class needs its class to be extended anyway to be executed, so this isn't an excuse. You could extend the abstract class (at the same time, implementing the abstract method). So this doesn't work as an explanation.
– PereJan 17 '17 at 16:11

A static method is a method that is associated with the class in which
it is defined rather than with any object. Every instance of the class
shares its static methods

In Java 8, along with default methods static methods are also allowed in an interface. This makes it easier for us to organize helper methods in our libraries. We can keep static methods specific to an interface in the same interface rather than in a separate class.

@MarsAtomic I think it's more appropriate then the top voted answer. Also , it's succinct.
– Praveen KumarSep 30 '15 at 7:46

Then you can edit earlier answers to improve them when you have sufficient rep. All you're doing is adding noise to the signal by creating duplicate answers. Please follow Stack Overflow's established rules and customs rather than creating your own and expecting everyone else to follow.
– MarsAtomicSep 30 '15 at 19:23

Regular methods can be abstract when they are meant to be overridden by subclasses and provided with functionality.
Imagine the class Foo is extended by Bar1, Bar2, Bar3 etc. So, each will have their own version of the abstract class according to their needs.

Now, static methods by definition belong to the class, they have nothing to do with the objects of the class or the objects of its subclasses. They don't even need them to exist, they can be used without instantiating the classes. Hence, they need to be ready-to-go and cannot depend on the subclasses to add functionality to them.

Declaring a method as static means we can call that method by its class name and if that class is abstract as well, it makes no sense to call it as it does not contain any body, and hence we cannot declare a method both as static and abstract.

Because if a class extends an abstract class then it has to override abstract methods and that is mandatory. And since static methods are class methods resolved at compile time whereas overridden methods are instance methods resolved at runtime and following dynamic polymorphism.