PROPOSAL: Static Methods in Interfaces (original) (raw)

Reinier Zwitserloot reinier at zwitserloot.com
Wed Mar 4 14:35:46 PST 2009

Hey Stephen,

Answers inline.

Summary:

  1. This proposal does not preclude future 'static implements'
    concepts. Because of similar terminology there might be more
    confusion, is all.

  2. No, you're mistaken, there is no backwards incompatibility.

--Reinier Zwitserloot

On Mar 4, 2009, at 22:32, Stephen Colebourne wrote:

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':

I'd like that as well, but it's not a key disadvantage. There are
plenty of ways to make that happen even if static methods are allowed
in interfaces. The only disadvantage here is that the existence of
this feature, as well as a static implements feature, can be slightly
more confusing that either one on its own.

Two rough sketches of static implements features that don't conflict
with the Static Methods in Interfaces proposal:

//separate interfaces from static-implements type interfaces entirely. public factory interface Foo { public static void someMethod(); }

or:

//use the 'abstract' keyword. public interface Foo { public abstract static void someMethod(); }

Either of those approaches would be fine.

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

I do. If there is a method that does useful things to Lists, provided
by the author(s) of the List interface, then it should be in List, or
at the very least, it should be possible to link the ListUtils class
to the List interface via something that IDEs will universally
recognize. If you'd like to propose a way to do that instead, for
example with an annotation, I could live with that as well, though
such a proposal would not cater as nicely to the 'other languages on
the JVM' crowd, and would not result in code that is as elegant. (I
consider List.of(foo, bar); a lot cleaner than ListUtils.of(foo,
bar);, but perhaps one can't argue taste).

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

I don't think it would be, because, as the proposal mentions, static
methods in interfaces do NOT inherit. So, If List.java did have a
static of method, then trying:

ArrayList.of(foo, bar);

would not be legal (method not found). So, if someone has rolled their
own List implementation that so happens to have a static of method,
then there's no problem at all:

List.of(); //finds List's of. MyOwnListImpl.of(); //finds your own of().

If of() isn't a static method, there is still no problem. The proposal
outlines that static calls via an instance aren't allowed either, so:

List x = new MyOwnListImpl(); x.of(); //wouldn't find EITHER method.

It won't find List.of() because you can't invoke static methods on
interfaces via an instance, and it won't find your own home-grown of
for the same reason you won't be allowed to call intValue() on a
variable of type Object that just so happens to hold an Integer
instance).

If I'm mistaken, please outline an example of a collision so I can add
a relevant paragraph in the 'compatibilities' section, but I don't
think there is one. It's one of the reasons why the proposal contains
the caveat that static methods in interfaces do not inherit at all.

More information about the coin-dev mailing list