| Claim | Verdict |
|---|
| Overloads can differ by return type | False. Constructors have no return type. |
| Overloads can differ by access modifier | False. That is the same signature. |
| Overloads can have different names | False. All are named after the class. |
| Each overload may validate independently | False in practice. Then validation drifts apart. |
this(...) may appear anywhere in the body | False. It must be the first statement. |
A class may use this and super together | False. Both must be first, so pick one. |
| Varargs accepts zero arguments | True. It hands you an empty array, so check it. |
| Overloads are chosen at run time | False. The compiler picks from static types. |
Frequently Asked Questions
What makes two constructors overloads rather than duplicates?
They must differ in their parameter list, whether in count, type, or order. They cannot differ by return type, because constructors declare none, and they cannot differ only by access modifier, because that yields the same signature. Identical parameter lists with any other difference are a compile error.
Why should overloaded constructors delegate to one another?
So validation and assignment live in a single place. When every constructor repeats the logic, adding a rule means editing each one, and a path that was missed keeps the old behaviour while appearing to be the same class. Delegating guarantees every object satisfies the same invariants regardless of which overload created it.
Where must the this call be placed?
As the first statement of the constructor body. The compiler has to resolve which overload the arguments belong to before it can compile anything else, so no statement may precede it. For the same reason you may use either this or super, never both.
What causes an ambiguous constructor call?
It happens when more than one overload matches the argument types equally well, and the compiler refuses to guess. Passing null for a parameter present in several overloads is the usual cause, as is a numeric literal that could match either an int or an Integer overload. Cast the argument to disambiguate, or remove the conflicting overload.
Does a varargs constructor accept a call with no arguments?
Yes, and it receives an empty array rather than null. So a varargs constructor must check the length and reject an empty call if that is not a valid state. Passing an explicit null instead gives you a null array, so both checks are needed, and you should clone the array to stop callers mutating your internal state.
When should I stop overloading constructors?
When the parameter list grows past about three. Each added optional field would need another constructor, and most combinations go unused. At that point a builder for many optional fields, a static factory method when the name should differ from the type, or a record for pure data will be clearer and cheaper to maintain.
When is the constructor chosen?
At compile time, from the static types of the arguments, and never from the runtime type of the objects involved. This is why passing a short literal where both an int and a long overload exist silently selects the int rather than the more convenient long.
How does constructor overloading differ from method overloading?
Only in naming. Both are resolved at compile time from the parameter list, and both forbid differing by return type. The differences are that every constructor is named after its class, that constructors declare no return type, that constructors are never inherited, and that an explicit this call can delegate from one overload to another.