PROPOSAL: Static Methods in Interfaces

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