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

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.

Answer 2

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 3

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.