In Java when one interface extends another, why would one redeclare a method in a subinterface?

Question

I've been looking at the JMS API from J2EE and found a strange behavior where certain methods that are declared in an interface (e.g., createQueue in Session) are declared again in the subinterfaces such as QueueSession, and with identical documentation.

Since an subinterface "inherits" all the method declarations of the interface it inherits, and since the JavaDoc tool has no problem sorting out the JavaDocs of the subinterface and creating an "inherited operations" list, I can't figure out what this achieves.

The only think of is that initially the call was in Session, and then moved to QueueSession when the specific subclass was created, though then I would have expected to see something in the documentation of the upperclass. But this is just conjecture.

So the question is: Is there a convincing reason to redeclare a method in a subinterface?

Answer 1

I have never seen a good reasoning for this. The best I have seen is that:

• It makes it clear what it is without having to see the parent
• It makes it easier to change what the class extends without having to figure out what interfaces it should implement

I don't like either suggestion. I think the likely cause is that while the code was being written the interfaces were written before the abstract classes and the developers didn't bother to remove the duplicate implements.

Never underestimate the laziness of a developer :-)

In the end no harm is done except that at class load time it probably takes a non-noticeable fraction of time longer to load a class with duplicate interfaces.

Answer 2

the only reason i know of is to widen the visibility of a method (i.e. clone from protected to public), but that does not seem to be the case here.

Answer 3

Having seen this happen on occasion while working for Sun, I can tell you how it usually happens. Someone defines an interface, let's say Alice, with some methods; many developers implement that interface.

Some time later, it's realized that they need some other interface, call it Bob, that has a subset of the methods of Alice, in order to allow it to serve as a base interface for another interface, Clara.

If you move the methods of Alice into Bob, you break all the code that implements Alice; you have to go back and at least recompile a whole bunch of code, some of which you may not own, and for political reasons can't break.

So you don't.

Answer 4

I would say no, there is no reason to do this. I can imagine a couple ways this could happen during the evolution of some code though. It's not uncommon to take an existing interface and pull a smaller super-interface out of it. In that circumstance, I can imagine leaving the existing interface but just changing it to extend from a new interface.

Answer 5

In Java 5 you can change the return type of a overriding method, by making it more specific. More commonly the documentation is different so the method has to be declared again.

However if the method and documentation are the same, there is no need for it. However, you will see plenty of code which isn't strictly needed. It is possible it was needed once, but something was changed so it is no longer needed. It is quite likely that it was never needed but was done because the developer thought something needed to be done when actually there wasn't a good basis for it.

BTW: Different people have different views of what is needed or handy to have or better to make explicit.