PROPOSAL: Static Methods in Interfaces

[Stephen Colebourne]

Reinier Zwitserloot wrote:
> MAJOR DISADVANTAGE:
> 
> No opportunity to use the static  
> keyword in interfaces for some sort of factory interface concept (an  
> interface for constructors and static methods).

I think this is a key one, as it limits future Java changes. I'd like to 
see Java support 'static implements':

public class Foo implements Bar, static Baz {
  ...
}

where any methods defined by Baz have to be implemented by Foo as static 
methods.

> ALTERNATIVES:
> 
> The usual solution to this problem right now is to offer a separate  
> utility class (a class that is not instantiable and contains only  
> static methods) that contain the utility methods, along with a  
> reference in the javadoc of the interface to this utility class. For  
> example, java.util.Collections is the utility class that goes with  
> Map, List, Set and other Java Collections API interfaces.

I don't consider the utils class to be a particularly bad alternative.

> java.util.List/Map/Set: All methods in java.util.Collections should  
> also be made available on the appropriate java collections API  
> interface.
> java.io.Closeable: should contain a utility method  
> 'closeAndIgnoreException' (arguably better suited on InputStream  
> instead).
> java.util.List/Set: Should contain an 'of' method that makes  
> unmodifiable lists and sets via varargs.
> java.io.FileFilter: Should contain an 'ofExtension(String)' method  
> that creates a FileFilter for the provided extension.

Making these changes would appear to be backwards incompatible if the 
implementing class already defines the method added to the interface.

Stephen