It was advocated by various people for awhile. For example Craig Larman recommended it in Java 2 Performance and Idiom Guide, 2000. Josh Bloch came out against the idea in Effective Java, 2001, and I don't think anyone's really been endorsing the idea since then.
[Bupjae Lee]: Unfortunely, javax.swing.WindowConstants does that; JDialog, JFrame, and JInternalFrame implement this interface.
[Marcos]: But not because is avoiding prefixing static members with class names. Or is it?
I agree. WindowConstants is actually a relatively sensible use of this idiom, because the point it is to publish constant values that users of the Swing classes need, in order to use the classes. Those constants are supposed to be part of the public API. If the same classes were designed today, WindowConstants would probably be replaced with a public enum instead.
A better example of a poor use of a constant interface would be ObjectStreamConstants, used by ObjectInputStream, ObjectOutputStream, and others. These constants are really used only internally by the classes that implement the interface; they are of no interest to programmers who are simply using the classes. They just clutter up the API and make it harder to understand.
"I'm not back." - Bill Harding, Twister
Joined: Jan 30, 2000
One disadvantage of interfaces is that one you publish them to other coders outside your own control, they represent a public commitment which can be difficult to change later. You don't know who else is using the interface and you don't know how, so you can't just add a new method to the interface without risking breaking the code of existing clients (if/when they upgrade). In comparison, if you'd used an abstract or concrete class, you could just add a new concrete method with no problems (usually).
It's possible to work around this by creating a new interface with extends or supplements the original one, and changing your concrete implementations to implement the new interface, instead of or in addition to the old one. That way you don't break existing client code. It's generally more work than adding a method to a class would be, but it's possible.
This disadvantage isn't a reason to abandon interfaces, but it is a reason to design your interfaces carefully, and think carefully before you publish a new interface in a new release. Spending some extra time designing things well now can save you many headaches later.