Home/ Questions/Q 3240002
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T18:02:08+00:00

I just looked up the Set interface and found that it mostly (or completely)

  • 0

I just looked up the Set interface and found that it mostly (or completely) only redeclares functions which are already in the Collection interface. Set itself extends Collection, so doesn’t that mean that the Set interface automatically has all the functions from Collection? So why are they redeclared then?

For example, Set redeclares this:

/**
 * Returns the number of elements in this set (its cardinality).  If this
 * set contains more than <tt>Integer.MAX_VALUE</tt> elements, returns
 * <tt>Integer.MAX_VALUE</tt>.
 *
 * @return the number of elements in this set (its cardinality)
 */
int size();

/**
 * Returns <tt>true</tt> if this set contains no elements.
 *
 * @return <tt>true</tt> if this set contains no elements
 */
boolean isEmpty();

And the declaration in Collection:

/**
 * Returns the number of elements in this collection.  If this collection
 * contains more than <tt>Integer.MAX_VALUE</tt> elements, returns
 * <tt>Integer.MAX_VALUE</tt>.
 *
 * @return the number of elements in this collection
 */
int size();

/**
 * Returns <tt>true</tt> if this collection contains no elements.
 *
 * @return <tt>true</tt> if this collection contains no elements
 */
boolean isEmpty();

This seems very redundant to me. Why not just define the Set interface as:

public interface Set<E> extends Collection<E> {}

I think there is no single difference between those interfaces, right?

Of course I am not asking about the different semantics / meaning of Set. I know that. I am just asking about if it technically (i.e. to the compiler) has any difference. I.e., speaking generally:

interface A { void foo(); }
interface B extends A { void foo(); }
interface C extends A {}

Now, is there any difference between A, B or C?

While the contract (i.e. what is said in the documentation) can really be different for some functions (as for add), there is a valid reason to redeclare them: To be able to put a new documentation, i.e. to define the new contract.

However, there are also functions (like isEmpty) which have exactly the same documentation / contract. Why are they also redeclared?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Technically for the compiler it makes no difference at all.

    However, a set cannot have duplicate entries whereas a Collection can. This is worth knowing about.

    Because of this, the methods semantics for parameters, return values and what happens can mean different things. Redeclaring also allows the javadoc to become more specific. For example for add():

    Set: @return true if this set did not already contain the specified element

    Collection: @return true if this collection changed as a result of the call

    The meaning for set is more specific.

    Even for methods that are not more specific, it enables the javadoc to be nicer. For example, for size() : “Returns the number of elements in this set (its cardinality).” which is closer to the language people used to mathematical sets will understand.

    The API documents summarise this by saying: “The Set interface places additional stipulations, beyond those inherited from the Collection interface, on the contracts of all constructors and on the contracts of the add, equals and hashCode methods. Declarations for other inherited methods are also included here for convenience. (The specifications accompanying these declarations have been tailored to the Set interface, but they do not contain any additional stipulations.)”

    • 0