Skip to end of metadata
Go to start of metadata

Java supports overloading methods and can distinguish between methods with different signatures. Consequently, with some qualifications, methods within a class can have the same name if they have different parameter lists. In method overloading, the method to be invoked at runtime is determined at compile time. Consequently, the overloaded method associated with the static type of the object is invoked even when the runtime type differs for each invocation.

For program understandability, do not introduce ambiguity while overloading (see MET50-J. Avoid ambiguous or confusing uses of overloading), and use overloaded methods sparingly [Tutorials 2013].

Noncompliant Code Example

This noncompliant code example attempts to use the overloaded display() method to perform different actions depending on whether the method is passed an ArrayList<Integer> or a LinkedList<String>:

public class Overloader {
  private static String display(ArrayList<Integer> arrayList) {
    return "ArrayList";
  }

  private static String display(LinkedList<String> linkedList) {
    return "LinkedList";
  }

  private static String display(List<?> list) {
    return "List is not recognized";
  }

  public static void main(String[] args) {
    // Single ArrayList
    System.out.println(display(new ArrayList<Integer>()));
    // Array of lists
    List<?>[] invokeAll = new List<?>[] {
        new ArrayList<Integer>(), 
        new LinkedList<String>(), 
        new Vector<Integer>()};

    for (List<?> list : invokeAll) {
      System.out.println(display(list));
    }
  }
}

At compile time, the type of the object array is List. The expected output is ArrayList, ArrayList, LinkedList, and List is not recognized (because java.util.Vector is neither an ArrayList nor a LinkedList). The actual output is ArrayList followed by List is not recognized repeated three times. The cause of this unexpected behavior is that overloaded method invocations are affected only by the compile-time type of their arguments: ArrayList for the first invocation and List for the others.

Compliant Solution

This compliant solution uses a single display method and instanceof to distinguish between different types. As expected, the output is ArrayList, ArrayList, LinkedList, List is not recognized:

public class Overloader {
  private static String display(List<?> list) {
    return (
      list instanceof ArrayList ? "Arraylist" : 
      (list instanceof LinkedList ? "LinkedList" : 
      "List is not recognized")
    );
  }

  public static void main(String[] args) {
    // Single ArrayList
    System.out.println(display(new ArrayList<Integer>()));

    List<?>[] invokeAll = new List<?>[] {
        new ArrayList<Integer>(), 
        new LinkedList<String>(), 
        new Vector<Integer>()};

    for (List<?> list : invokeAll) {
      System.out.println(display(list));
    }
  }
}

Applicability

Ambiguous uses of overloading can lead to unexpected results.

Bibliography

 


5 Comments

  1. for starters, we probably should use the variable name "l' which looks like a one. In fact, I think we have a guideline about this.

    1. Don't you mean "shouldn't"??

  2. Possible heuristic: Look for overloaded methods where one or more arguments have a common ancestor type other than Object.

  3. I'm a little confused about the difference between this and MET50-J. Avoid ambiguous or confusing uses of overloading. Is it:

    MET50-J. = don't write ambiguous overloads

    MET51-J. = don't use the ambiguous overloads that we just told you (MET50-J.) not to write!

    1. There are examples of non-ambiguous overloads. That is, the signatures differ in some nontrivial way. For example foo(int x) vs foo(String x) are non-ambiguous. Neither MET50-J nor MET51-J forbid such overloading.