PROPOSAL: Static Methods in Interfaces (original) (raw)
Stephen Colebourne scolebourne at joda.org
Wed Mar 4 13:32:51 PST 2009
- Previous message: PROPOSAL: Static Methods in Interfaces
- Next message: PROPOSAL: Static Methods in Interfaces
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: PROPOSAL: Static Methods in Interfaces
- Next message: PROPOSAL: Static Methods in Interfaces
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]