Methods

Method overloading is having several methods with the same name in the same class but different parameter lists (different number or types of parameters). The compiler picks the right one based on the arguments you pass.

Java is always pass-by-value. The method gets a copy of the argument. For an object, that copy is a copy of the reference (the address), not a copy of the object itself.

Recursion is when a method calls itself to solve a smaller piece of a problem. The base case is the simple input that stops the calling, so the method does not call itself forever and eventually returns an answer.

Varargs (variable arguments) let a method accept any number of arguments of one type, written as Type... name. Inside the method, name is an array. You call it like sum(1, 2, 3) or pass an array.

A method's signature is its name plus the number, types, and order of its parameters. The return type, parameter names, modifiers, and throws clause are NOT part of the signature.

Overloading is same method name with different parameter lists, chosen by the compiler from the argument types (compile time). Overriding is a subclass replacing a superclass method with the same signature, chosen by the object's real type at runtime.

No. The method got a copy of the reference pointing at the same list, so add() changes the shared list. That's mutation, not pass-by-reference. If the method did list = new ArrayList<>(), the caller would see nothing change.

Each method call uses a chunk of stack memory (a frame). The thread stack has a fixed limited size. Too many nested recursive calls fill it up, and the JVM throws StackOverflowError. How deep you can go depends on the stack size and how much each frame uses.

A parameter is the variable named in the method declaration (the placeholder). An argument is the actual value you pass when you call the method. Parameters are in the definition; arguments are at the call.

To trace recursion, substitute the call by hand: replace each call with its body until you reach the base case, then combine the results on the way back. To check correctness, make sure the base case returns the right answer and that every recursive call moves the input closer to the base case.

return ends the method and hands a value back to the caller. In a non-void method every path must return a value of the right type. In a void method you can write a bare 'return;' to exit early but cannot return a value.

It happens when, in a given resolution phase, two or more overloads are equally applicable to your arguments and neither is more specific than the other, so the compiler cannot decide. You fix it by casting an argument to pin the intended overload.

A swap method only gets copies of the references. Swapping them inside the method just swaps the local copies; the caller's variables are untouched. To swap, you must mutate a shared container the caller can see, like an array or holder object.

Recursion is great when the data or problem is self-similar, like trees or nested structures, because the code mirrors the structure and is short and clear. Iteration with a loop uses constant stack space and is faster, so it is safer for deep or large inputs. Pick recursion for clarity on shaped data, iteration for depth and performance.

Each varargs call (with loose arguments) creates a new array on the heap to hold them. That allocation is cheap individually but adds up on hot paths called millions of times, creating garbage-collection pressure.

Use varargs when a method naturally takes 'any number' of one type, like log(String...) or sum(int...). Avoid forcing it where a list is clearer, and require at least one mandatory value with a fixed first parameter when zero arguments make no sense.

The throws clause lists the exceptions a method might pass up to its caller. For checked exceptions, the compiler forces you to declare them with throws (or catch them). Unchecked exceptions (RuntimeException, Error) don't need to be declared.

Java tries to find the right overload in three passes: first without auto-converting primitives (no boxing) and without varargs, then allowing boxing/unboxing, and finally allowing varargs. It uses the first phase that finds a match.

Integer and String are immutable. Operations like p++ or p += "x" don't change the object; they create a new object and point the local parameter at it. Since the parameter is a copy of the reference, the caller's variable still points at the original. No change is visible.

No. A tail call is a recursive call that is the very last thing a method does. Some languages reuse the same stack frame for it so it never overflows, but standard Java does not. So even tail-recursive Java methods add a frame per call and can still throw StackOverflowError on deep input.

When choosing between overloaded methods, the compiler tries non-varargs (fixed-arity) matches first. Only if none fit does it consider varargs methods. So a more specific fixed overload always beats a varargs one.

Because methods get a copy of the reference to the same object, any mutable object you pass can be changed by the callee, and anything mutable you return can be changed by the caller. So copy mutable inputs/outputs defensively, or make objects immutable so copying isn't needed.

Mixing generics with varargs creates a generic array under the hood, which Java can't fully type-check, so the compiler warns about possible 'heap pollution.' If the method only reads the array safely, you annotate it @SafeVarargs to suppress the warning.

Modifiers change a method's nature: static means it belongs to the class not an instance; abstract means no body; final means it can't be overridden; synchronized adds locking; access modifiers control visibility. Some combinations (like abstract final or abstract static) are illegal because they contradict each other.

Avoid overloading when overloads have the same number of parameters and callers can't easily tell which one runs — it causes confusion, ambiguity, and surprising selection by static types. Prefer distinct, descriptive method names in those cases.