Page History

Unlike method overriding, in method overloading the choice of which method to invoke 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. Even if Consequently, the overloaded method associated with the static type of the object is invoked even when the runtime type differs for each invocation, in overloading, the method invocations depend on the type of the object at compile time.

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 shows how the programmer can confuse overloading with overriding. At compile time, the type of the object array is {{List}}. The expected output is {{ArrayList}}, {{LinkedList}} and {{List is not recognized}} ({{java.util.Vector}} does not inherit from {{java.util.List}}). However, in all three instances {{List is not recognized}} is displayed. This happens because in overloading, the method invocations are not affected by the runtime types but only the compile time type ({{List}}). It is dangerous to implement overloading to tally with overriding, more so, because the latter is characterized by inheritance unlike the former. \[[Bloch 2008|AA. Java References#Bloch 08]\]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>:

Code Block

bgColor	#FFCCCC


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

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

  private static String display(List<?> llist) {
    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<?> ilist : invokeAll) {
      System.out.println(display(ilist));
    }
  }
}

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

Wiki MarkupThis 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}}. As a general rule, do not introduce ambiguity while overloading so that the code is clean and easy to understand. \[[Bloch 2008|AA. Java References#Bloch 08]\]recognized:

Code Block

bgColor	#ccccff


class Overloader {
public class Overloader {
  private static String display(List<?> llist) {
    return (l
      list instanceof ArrayList ? "Arraylist" : (l
      (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<?> ilist : invokeAll) {
      System.out.println(display(ilist));
    }
  }
}

...

Applicability

Ambiguous uses of overloading can lead to unexpected results.

Rule	Severity	Likelihood	Remediation Cost	Priority	Level
MET05- J	low	unlikely	high	P1	L3

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

Wiki Markup

\[[API 2006|AA. Java References#API 06]\] [Interface Collection|http://java.sun.com/j2se/1.4.2/docs/api/java/util/Collection.html]
\[[Bloch 2008|AA. Java References#Bloch 08]\] Item 41: Use overloading judiciously

Bibliography

[API 2013]	Interface Collection<E>
[Bloch 2008]	Item 41, "Use Overloading Judiciously"
[Tutorials 2013]	Defining Methods

...

Image Added Image Added Image Added MET04-J. Ensure that constructors do not call overridable methods 16. Methods (MET) MET06-J. Do not call overridable methods from a privileged block

Space shortcuts

Page tree

Versions Compared

Old Version 19

New Version Current

Key