Java 8: Interface with static methods instead of static util class

Question

What is best practice in Java 8 when I need a bunch of stateless utility methods. Is it right to have an interface that will not be implemented by anyone i.e. public interface Signatures and public interface Environments, or is it better to do it the old way - have public final class Signatures and public final class Environments with private constructors || enums?

Answer 1

The main purpose of interfaces is to provide a type and a vocabulary of operations (methods) on that type. They're useful and flexible because they allow multiple implementations, and indeed they are designed to allow implementations that are otherwise unrelated in the class hierarchy.

The question asks,

Is it right to have an interface that will not be implemented by anyone...?

This seems to me to cut against the grain of interfaces. One would have to look around the API to determine that there are no classes that implement this interface, and that there are no producers or consumers of this interface. Somebody might be confused and try to create an implementation of the interface, but of course they wouldn't get very far. While it's possible to have a "utility interface" with all static methods, this isn't as clear as the old unconstructible final class idiom. The advantage of the latter is that the class can enforce that no instances can ever be created.

If you look at the new Java 8 APIs, you'll see that the final class idiom is still used despite the ability to add static methods on interfaces.

Static methods on interfaces have been used for things like factory methods to create instances of those interfaces, or for utility methods that have general applicability across all instances of those interfaces. For example, see the Stream and Collector interfaces in java.util.stream. Each has static factories: Stream.of(), Stream.empty(), and Collector.of().

But also note that each has companion utility classes StreamSupport and Collectors. These are pure utility classes, containing only static methods. Arguably they could be merged into the corresponding interfaces, but that would clutter the interfaces, and would blur the relationship of the methods contained in the classes. For example, StreamSupport contains a family of related static methods that are all adapters between Spliterator and Stream. Merging these into Stream would probably make things confusing.

Answer 2

I would use the final class. Communicates to me better that it is a helper class with some utility methods. An interface definition is something I would expect to be implemented and the methods to be there to assist someone implement the interface.