Helper classes

Brian Goetz brian.goetz at
Mon Apr 15 15:12:51 PDT 2013

We probably won't know what the first rule is for quite a while, but I 
think the line of reasoning you're following here is a good one to 
explore, and may well lead somewhere good.

Regretfully, I can immediately think of a countervailing design force; 
that interface instance methods are inherited and interface static 
methods are not.  (This was a deliberate choice; the EG viewed the 
inheritability of static methods in classes (or the ability to invoke 
them through instances) to be a bug, and one which would have even more 
harm under multiple inheritance than under single inheritance.)  As 
such, adding new instance methods after-the-fact has a higher risk of 
clashing with existing methods in existing implementations, or simply 
being a mismatch by the time you get far enough down the inheritance 
tree, because every subtype has to take it.  Adding a static to an 
interface can't interfere with anything down-tree.

But I think you're headed in the right direction.

On 4/15/2013 5:54 PM, Stephen Colebourne wrote:
> On 15 April 2013 22:41, Brian Goetz <brian.goetz at> wrote:
>> An example of a method at the other end of the spectrum is
>> Collections.rotate(List, int).  Sure, this is useful when you need it,
>> but it just isn't that important, and weighing down an interface with
>> 5000 lines of additional code (OK, Collections is only 4700 LoC) really
>> clogs up the Collection interface.
> Perhaps there is a semblance of a first rule here.
> - Collections.rotate(List, int)  - static
> could now be:
> - List.rotate(List, int)  - static
> but that would just look and behave weirdly, because it should be
> - List.rotate(int)  - instance
> But, most of us would agree that an instance method for rotating
> probably isn't justified. Thus it is also not justified as a static
> method on the same interface.
> The rule is therefore along the lines of "don't add a static method
> where one of its arguments is the same type as the interface and the
> methods purpose is to operate on that argument. Either use a default
> instance method on the interface, or keep it in a separate utility
> class".
> Stephen

More information about the lambda-dev mailing list