Page History

...

Notably, constructors cannot be overridden and can only be overloaded. Failure to exercise caution while passing arguments to them can create confusion as two overloadings can contain the same number of similarly typed parameters. This noncompliant code example shows the constructor Con with three overloadings Con(int, String), Con(String, int) and Con(Integer, String). Overloading should also be avoided when the overloaded methods provide inconsistent functionality for arguments of the same types, differing just in their declaration order. This noncompliant code example violates both these conditions.

class Con {
  public Con(int i, String s) { /* Initialization Sequence #1 */ }
  public Con(String s, int i) { /* Initialization Sequence #2 */ } 
  public Con(Integer i, String s) { /* Initialization Sequence #3 */ } 
}

Failure to exercise caution while passing arguments to them can create confusion as two overloadings can contain the same number of similarly typed parameters. Overloading should also be avoided when the overloaded constructors or methods provide inconsistent functionality for arguments of the same types, differing just in their declaration order. This noncompliant code example violates both these conditions.

Compliant Solution

To be compliant, prefer the use of public static factory methods over public class constructors.

...

This program provides another concrete example of noncompliance. The InformationLeak class holds a HashMap instance and returns a particular record to the caller based on either its key value in the map or the actual mapped value. The getData() method has been overloaded to return the contained data indexed by the key value in one case, whereas in the other, it checks whether a particular record exists before formatting and returning it as a String object. The InformationLeak class inherits from java.util.HashMap and overrides its get() method to provide the checking functionality. This implementation can be extremely confusing to the client who will expect the getData() methods to behave identically and not variably, depending on whether an index of the record is specified or the retrievable value to be retrieved.

Worse, in the presence of autoboxing, an innocent int argument may end up invoking the undesired overloading for Integer. This can happen if the overloading with the primitive int type is added to a class at a later date. Clients who expect the getData() method to fetch data based on its value will suddenly start invoking the new overloading whenever an int argument is passed and proceed to return the record by index. This happens because a primitive argument becomes more specific in the new version whereas in the old one, autoboxing allows the selection of the method with the Integer type parameter when an int is passed.

...

... the List<E> interface has two overloadings of the remove method: remove(E) and remove(int). Prior to release 1.5 when it was "generified", the List interface had a remove(Object) method in place of remove(E), and the corresponding parameter types, Object and int, were radically different. But in the presence of generics and autoboxing, the two parameter types are no longer radically different.

Consequently, a client may not realize that the wrong element has been removed from the list.

Compliant Solution

Naming the two related methods differently disqualifies the overloading and is highly recommended in this case.

...