[ACCEPTED]-Why no static methods in Interfaces, but static fields and inner classes OK? [pre-Java8]-jls

Accepted answer
Score: 49

An official proposal has been made to allow static methods 16 in interfaces in Java 7. This proposal is 15 being made under Project Coin.

My personal opinion is 14 that it's a great idea. There is no technical 13 difficulty in implementation, and it's a 12 very logical, reasonable thing to do. There 11 are several proposals in Project Coin that 10 I hope will never become part of the Java language, but 9 this is one that could clean up a lot of 8 APIs. For example, the Collections class has static methods for manipulating 7 any List implementation; those could be included 6 in the List interface.


Update: In the Java Posse Podcast #234, Joe D'arcy mentioned 5 the proposal briefly, saying that it was 4 "complex" and probably would not 3 make it in under Project Coin.


Update: While they 2 didn't make it into Project Coin for Java 1 7, Java 8 does support static functions in interfaces.

Score: 40

I'm going to go with my pet theory with 19 this one, which is that the lack of consistency 18 in this case is a matter of convenience 17 rather than design or necessity, since I've 16 heard no convincing argument that it was 15 either of those two.

Static fields are there 14 (a) because they were there in JDK 1.0, and 13 many dodgy decisions were made in JDK 1.0, and 12 (b) static final fields in interfaces are 11 the closest thing java had to constants 10 at the time.

Static inner classes in interfaces 9 were allowed because that's pure syntactic 8 sugar - the inner class isn't actually anything 7 to do with the parent class.

So static methods 6 aren't allowed simply because there's no 5 compelling reason to do so; consistency 4 isn't sufficiently compelling to change 3 the status quo.

Of course, this could be 2 permitted in future JLS versions without 1 breaking anything.

Score: 15

There is never a point to declaring a static 26 method in an interface. They cannot be executed 25 by the normal call MyInterface.staticMethod(). (EDIT:Since 24 that last sentence confused some people, calling 23 MyClass.staticMethod() executes precisely 22 the implementation of staticMethod on MyClass, which 21 if MyClass is an interface cannot exist!) If 20 you call them by specifying the implementing 19 class MyImplementor.staticMethod() then 18 you must know the actual class, so it is 17 irrelevant whether the interface contains 16 it or not.

More importantly, static methods 15 are never overridden, and if you try to 14 do:

MyInterface var = new MyImplementingClass();
var.staticMethod();

the rules for static say that the method 13 defined in the declared type of var must 12 be executed. Since this is an interface, this 11 is impossible.

You can of course always 10 remove the static keyword from the method. Everything 9 will work fine. You may have to suppress 8 some warnings if it is called from an instance 7 method.

To answer some of the comments below, the 6 reason you can't execute "result=MyInterface.staticMethod()" is 5 that it would have to execute the version 4 of the method defined in MyInterface. But 3 there can't be a version defined in MyInterface, because 2 it's an interface. It doesn't have code 1 by definition.

Score: 6

The purpose of interfaces is to define a 12 contract without providing an implementation. Therefore, you 11 can't have static methods, because they'd 10 have to have an implementation already in 9 the interface since you can't override static 8 methods. As to fields, only static final fields are 7 allowed, which are, essentially, constants 6 (in 1.5+ you can also have enums in interfaces). The 5 constants are there to help define the interface 4 without magic numbers.

BTW, there's no need 3 to explicitly specify static final modifiers for fields 2 in interfaces, because only static final 1 fields are allowed.

Score: 6

This is an old thread , but this is something 22 very important question for all. Since i 21 noticed this today only so i am trying to 20 explain it in cleaner way:

The main purpose 19 of interface is to provide something that 18 is unimplementable, so if they provide

static 17 methods to be allowed

then you can call 16 that method using interfaceName.staticMethodName(), but this is unimplemented 15 method and contains nothing. So it is useless 14 to allow static methods. Therefore they 13 do not provide this at all.

static fields 12 are allowed

because fields are not implementable, by 11 implementable i mean you can not perform 10 any logical operation in field, you can 9 do operation on field. So you are not changing 8 behavior of field that is why they are allowed.

Inner 7 classes are allowed

Inner classes are allowed 6 because after compilation different class 5 file of the Inner class is created say InterfaceName$InnerClassName.class , so 4 basically you are providing implementation 3 in different entity all together but not 2 in interface. So implementation in Inner 1 classes is provided.

I hope this would help.

Score: 3

Prior to Java 5, a common usage for static 4 fields was:

interface HtmlConstants {
    static String OPEN = "<";
    static String SLASH_OPEN = "</";
    static String CLOSE = ">";
    static String SLASH_CLOSE = " />";
    static String HTML = "html";
    static String BODY = "body";
    ...
}

public class HtmlBuilder implements HtmlConstants { // implements ?!?
    public String buildHtml() {
       StringBuffer sb = new StringBuffer();
       sb.append(OPEN).append(HTML).append(CLOSE);
       sb.append(OPEN).append(BODY).append(CLOSE);
       ...
       sb.append(SLASH_OPEN).append(BODY).append(CLOSE);
       sb.append(SLASH_OPEN).append(HTML).append(CLOSE);
       return sb.toString();
    }
}

This meant HtmlBuilder would not have to 3 qualify each constant, so it could use OPEN instead 2 of HtmlConstants.OPEN

Using implements in this way is ultimately confusing.

Now with Java 5, we have the import static syntax 1 to achieve the same effect:

private final class HtmlConstants {
    ...
    private HtmlConstants() { /* empty */ }
}

import static HtmlConstants.*;
public class HtmlBuilder { // no longer uses implements
    ...
}
Score: 3

Actually sometimes there are reasons someone 9 can benefit from static methods. They can 8 be used as factory methods for the classes 7 that implement the interface. For example 6 that's the reason we have Collection interface 5 and the Collections class in openjdk now. So 4 there are workarounds as always - provide 3 another class with a private constructor 2 which will serve as a "namespace" for the 1 static methods.

Score: 3

There is no real reason for not having static 10 methods in interfaces except: the Java language 9 designers did not want it like that. From 8 a technical standpoint it would make sense 7 to allow them. After all an abstract class 6 can have them as well. I assume but did 5 not test it, that you can "hand craft" byte 4 code where the interface has a static method 3 and it should imho work with no problems 2 to call the method and/or to use the interface 1 as usually.

Score: 2

I often wonder why static methods at all? They 3 do have their uses, but package/namespace 2 level methods would probably cover 80 of 1 what static methods are used for.

Score: 1

Two main reasons spring to mind:

  1. Static methods 17 in Java cannot be overridden by subclasses, and 16 this is a much bigger deal for methods than 15 static fields. In practice, I've never 14 even wanted to override a field in a subclass, but 13 I override methods all the time. So having 12 static methods prevents a class implementing 11 the interface from supplying its own implementation 10 of that method, which largely defeats the 9 purpose of using an interface.

  2. Interfaces 8 aren't supposed to have code; that's what 7 abstract classes are for. The whole point 6 of an interface is to let you talk about 5 possibly-unrelated objects which happen 4 to all have a certain set of methods. Actually 3 providing an implementation of those methods 2 is outside the bounds of what interfaces 1 are intended to be.

Score: 1

Static methods are tied to a class. In 13 Java, an interface is not technically a 12 class, it is a type, but not a class (hence, the 11 keyword implements, and interfaces do not 10 extend Object). Because interfaces are 9 not classes, they cannot have static methods, because 8 there is no actual class to attach to.

You 7 may call InterfaceName.class to get the 6 Class Object corresponding to the interface, but 5 the Class class specifically states that 4 it represents classes and interfaces in 3 a Java application. However, the interface 2 itself is not treated as a class, and hence 1 you cannot attach a static method.

Score: 0

Only static final fields may be declared 11 in an interface (much like methods, which 10 are public even if you don't include the 9 "public" keyword, static fields are "final" with 8 or without the keyword).

These are only values, and 7 will be copied literally wherever they are 6 used at compile time, so you never actually 5 "call" static fields at runtime. Having 4 a static method would not have the same 3 semantics, since it would involve calling 2 an interface without an implementation, which 1 Java does not allow.

Score: 0

The reason is that all methods defined in 13 an interface are abstract whether or not 12 you explicitly declare that modifier. An 11 abstract static method is not an allowable 10 combination of modifiers since static methods 9 are not able to be overridden.

As to why 8 interfaces allow static fields. I have a 7 feeling that should be considered a "feature". The 6 only possibility I can think of would be 5 to group constants that implementations 4 of the interface would be interested in.

I 3 agree that consistency would have been a 2 better approach. No static members should 1 be allowed in an interface.

Score: 0

I believe that static methods can be accessed 10 without creating an object and the interface 9 does not allow creating an object as to 8 restrict the programmers from using the 7 interface methods directly rather than from 6 its implemented class. But if you define 5 a static method in an interface, you can 4 access it directly without its implementation. Thus 3 static methods are not allowed in interfaces. I 2 don't think that consistency should be a 1 concern.

Score: 0

Java 1.8 interface static method is visible 29 to interface methods only, if we remove 28 the methodSta1() method from the InterfaceExample 27 class, we won’t be able to use it for the 26 InterfaceExample object. However like other 25 static methods, we can use interface static 24 methods using class name. For example, a 23 valid statement will be: exp1.methodSta1();

So 22 after looking below example we can say : 1) Java 21 interface static method is part of interface, we 20 can’t use it for implementation class objects.

2) Java 19 interface static methods are good for providing 18 utility methods, for example null check, collection 17 sorting ,log etc.

3) Java interface static 16 method helps us in providing security by 15 not allowing implementation classes (InterfaceExample) to 14 override them.

4) We can’t define interface 13 static method for Object class methods, we 12 will get compiler error as “This static 11 method cannot hide the instance method from 10 Object”. This is because it’s not allowed 9 in java, since Object is the base class 8 for all the classes and we can’t have one 7 class level static method and another instance 6 method with same signature.

5) We can 5 use java interface static methods to remove 4 utility classes such as Collections and 3 move all of it’s static methods to the corresponding 2 interface, that would be easy to find 1 and use.

public class InterfaceExample implements exp1 {

    @Override
    public void method() {
        System.out.println("From method()");
    }

    public static void main(String[] args) {
        new InterfaceExample().method2();
        InterfaceExample.methodSta2();      //  <---------------------------    would not compile
        // methodSta1();                        //  <---------------------------    would not compile
        exp1.methodSta1();
    }

    static void methodSta2() {          //          <-- it compile successfully but it can't be overridden in child classes
        System.out.println("========= InterfaceExample :: from methodSta2() ======");
    }
}


interface exp1 {

    void method();
    //protected void method1();         //          <--      error
    //private void method2();           //          <--      error
    //static void methodSta1();         //          <--      error it require body in java 1.8

    static void methodSta1() {          //          <-- it compile successfully but it can't be overridden in child classes
        System.out.println("========= exp1:: from methodSta1() ======");
    }

    static void methodSta2() {          //          <-- it compile successfully but it can't be overridden in child classes
        System.out.println("========= exp1:: from methodSta2() ======");
    }

    default void method2() { System.out.println("---  exp1:: from method2() ---");}
    //synchronized default void method3() { System.out.println("---");}             // <-- Illegal modifier for the interface method method3; only public, abstract, default, static 
                                                                                // and strictfp are permitted
    //final default void method3() { System.out.println("---");} //             <--      error
}

More Related questions