🧩 Methods · Beginner

Method signature in Java

Name + parameter types; return type is not part of it.

🧩 The mysteryint size() and long size() in the same class. Different return types, so different methods, right? The compiler says no. What is it actually comparing?

A method's ID card

A method's signature is its name plus the types of its parameters, in order. That's how the compiler tells methods apart. For public static double area(double w, double h), the signature is just **area(double, double)**.

public static double area(double w, double h)
// signature: area(double, double)

What doesn't count

Not part of the signature: the return type, the parameter names, the modifiers (public, static...) and the throws clause. Within one class, no two methods may share a signature: that's a compile error (method is already defined).

int max(int a, int b)
// signature: max(int, int)
double max(double a, double b)
// signature: max(double, double)

🔮 Predict it

Your turn

Different return types, different parameter names. What happens?

static int parse(String s) {
    return 1;
}
static double parse(String text) {
    return 1.0;
}
void main() {
    System.out.println(parse("x"));
}

Prints 1
Prints 1.0
Compile error

Show the answer

Compile error. Both have the signature parse(String). Return type and parameter names don't count, so the second one is "already defined".

🤔 Think first

Why not the return type?

Why doesn't Java let methods differ by return type alone?

Think about it, then reveal the answer

Because a call doesn't always say what it expects back. For size(); with the result ignored, the compiler would have no way to choose. It picks a method from the call expression alone: name and argument types.

Order matters

Parameter order is part of the signature. log(String, int) and log(int, String) are different, so both may live in one class. Different types work too: p(int) and p(long) can coexist.

void log(String s, int n)  // log(String, int)
void log(int n, String s)  // log(int, String)
void p(int a)              // p(int)
void p(long a)             // p(long)

⚠️ The trap

Renaming isn't overloading

Changing only the parameter names, the return type or the modifiers leaves the signature identical. All three pairs below are compile errors: they're all p(int).

void p(int a)   +  void p(int b)
void p(int a)   +  int p(int a)
void p(int a)   +  static void p(int x)
// each pair: p(int) twice -> error

💼 In the real world

In real projects

Signatures matter when libraries evolve. You can't keep an old method and add a new one that only changes its return type: you need a new name or different parameters. Changing a public method's signature also breaks every caller compiled against the old version.

Key takeaways

Signature = name + parameter types, in order
Not included: return type, parameter names, modifiers
Two methods with the same signature in one class: compile error
Changing the parameter order changes the signature

🤯 Did you know?

Inside .class files, the JVM identifies methods by name plus a descriptor that DOES include the return type. The compiler quietly uses this for generated "bridge methods" that differ only by return type.

Practice questions

What is the signature of: public static double area(double w, double h)

double area(double w, double h)
area(double, double)
public static double area
area(w, h)

Check your answer

area(double, double). Only the name and the parameter types count. Modifiers, return type and parameter names are left out.

What does this print?

static int size() {
    return 1;
}
static long size() {
    return 2L;
}
void main() {
    System.out.println(size());
}

1
2
Compile error

Check your answer

Compile error. Both methods have the signature size(). The compiler reports that size() is already defined.

Next: the secret to code that's easy to test: methods that never touch anything outside themselves.