This post originated from an RSS feed registered with Java Buzz by Marc Logemann. Original Post: why i want static methods in interfaces Feed Title: Marc's Java Blog Feed URL: http://www.logemann.org/day/index_java.xml Feed Description: Java related topics for all major areas. So you will see J2ME, J2SE and J2EE issues here. Latest Java Buzz Posts Latest Java Buzz Posts by Marc Logemann Latest Posts From Marc's Java Blog

Because i want to create a contract that every class should contain a factory method for creating itself from a given array.

I read several discussions about that issue and i dont know why Sun decided to go this way. Is this idea so crazy? I dont think so. Assume this:

public interface ArrayCreatable {
Object createFromArray(String[] array);
}

public class A implements ArrayCreatable {
...
}

public class B implements ArrayCreatable {
...
}

The point is, when i want to construct an A or B, i just can say:
A a = (A) A.createFromArray(..);
B b = (B) B.createFromArray(..);

Because this is not possible, the only way is to declare an interface and let the createFromArray() be an instance method, but on construction, i am ending with something like this:

A a = new A();
a.createFromArray(..);

I wont die if i do it this way, but the other one is shorter and resembles the well know factory pattern. From a technical point of view, i dont know why Sun has opted for the way it is. Perhaps someone can enlighten me, other than, "hey dude, interface methods are implicitely abstract, so they cant be static". Even this is correct, its not the question.