{"title":"Method Parameters","description":"","content":"The previous lesson introduced methods as named blocks of code. Most of those examples used methods that took no inputs, which only gets so far. Real methods need data to work with: a product's price, a customer's name, a list of items in a cart. Parameters are how that data flows into a method. This lesson covers the rules for declaring parameters, the difference between what the method signature says and what the call site provides, and the small handful of patterns that prevent the most common bugs.\n\n---\n\n# Parameters vs Arguments\n\nThe two words sound interchangeable, and they are often used that way, but Java draws a clean line between them.\n\nA **parameter** is what shows up in the method declaration. It's the variable name and its type, sitting inside the parentheses next to the method name. The parameter exists only inside the method body. Outside the method, the name means nothing.\n\nAn **argument** is what gets passed when the method is called. It's the actual value the caller hands over: a literal like `29.99`, a variable like `itemPrice`, or an expression like `quantity * unitPrice`.\n\n\n```java\npublic class CartPrinter {\n public static void main(String[] args) {\n double price = 19.99;\n printPrice(price);\n printPrice(29.99);\n printPrice(price * 2);\n }\n\n // 'amount' is the parameter\n static void printPrice(double amount) {\n System.out.println(\"Price: $\" + amount);\n }\n}\n```\n\n\nInside `printPrice`, the value lives under the name `amount`. The caller never has to know that name. The caller hands over a number (the argument), and the method receives it under whatever name it chose for the parameter.\n\nWhen \"parameter\" and \"argument\" are used interchangeably, the meaning usually carries through. In documentation, error messages, or interview questions, the distinction matters. \"Argument type mismatch\" points at the call site. \"Parameter type\" points at the declaration.\n\nRead the parameter as the slot, and the argument as the thing that fills the slot. The slot is named and typed once, in the method declaration. The thing that fills it can be a different value every call.\n\n---\n\n# A Single Parameter\n\nThe simplest method takes one piece of data and does something with it. Declare the type, then the name, all inside the parentheses.\n\n\n```java\npublic class GreetCustomer {\n public static void main(String[] args) {\n greet(\"Alice\");\n greet(\"Bob\");\n }\n\n static void greet(String customerName) {\n System.out.println(\"Welcome back, \" + customerName + \"!\");\n }\n}\n```\n\n\nThe same `greet` method runs twice with different inputs. That's the point of a parameter: write the logic once, feed it different data each time.\n\nThe parameter name `customerName` is local to the method. It lives only between the opening brace and the closing brace of `greet`. The caller's variable, if there is one, doesn't have to share the name.\n\n\n```java\npublic class CallerNames {\n public static void main(String[] args) {\n String name = \"Carol\";\n greet(name);\n\n String shopper = \"Dave\";\n greet(shopper);\n }\n\n static void greet(String customerName) {\n System.out.println(\"Welcome back, \" + customerName + \"!\");\n }\n}\n```\n\n\nThe caller's variable can be called `name`, `shopper`, or anything else. Inside the method, the value shows up as `customerName` because that's what the parameter is named.\n\n---\n\n# Multiple Parameters\n\nMethods can take more than one input. Separate parameters with commas. Each one needs its own type, even if two parameters happen to share the same type.\n\n\n```java\npublic class CartTotal {\n public static void main(String[] args) {\n printSubtotal(29.99, 3);\n printSubtotal(9.50, 5);\n }\n\n static void printSubtotal(double itemPrice, int quantity) {\n double subtotal = itemPrice * quantity;\n System.out.println(\"Subtotal: $\" + subtotal);\n }\n}\n```\n\n\nEach parameter has its own type. Writing `double itemPrice, quantity` does not make `quantity` also a `double`, the way two variables on one line work in normal code. In a parameter list, every parameter is a fresh declaration.\n\n\n```java\npublic class WrongSyntax {\n // Won't compile: 'int quantity' is fine, but 'double a, b' is not allowed here.\n // static void wrong(double a, b) { ... }\n\n static void right(double a, double b) {\n System.out.println(a + b);\n }\n}\n```\n\n\nThe compiler error for the bad version is roughly:\n\n\n```shell\nerror: expected\n static void wrong(double a, b) { ... }\n ^\n```\n\n\nEach parameter must have an explicit type.\n\n---\n\n# Parameter Order Matters\n\nA method's parameters are matched to the arguments by position, not by name. The first argument fills the first parameter slot, the second argument fills the second, and so on. Swapping the order at the call site changes the meaning.\n\n\n```java\npublic class OrderMatters {\n public static void main(String[] args) {\n applyDiscount(100.0, 20.0);\n applyDiscount(20.0, 100.0);\n }\n\n static void applyDiscount(double price, double discountPercent) {\n double off = price * discountPercent / 100.0;\n double finalPrice = price - off;\n System.out.println(\"Price: $\" + price + \", you pay: $\" + finalPrice);\n }\n}\n```\n\n\nThe second call passes `20.0` as the price and `100.0` as the discount percent, which makes no sense as a discount. Java doesn't warn about this because both arguments are valid `double` values, and the types match. The bug is only visible from the output.\n\nWhen two parameters share a type, the only safeguard against the wrong order is reading the method signature carefully. Helpful parameter names are part of that. `applyDiscount(double price, double discountPercent)` reads better than `applyDiscount(double a, double b)` precisely because the names tell what goes in which slot.\n\n---\n\n# Naming Parameters\n\nA parameter's name is just a label, but the label affects every reader of the code. A few habits go a long way.\n\nUse names that describe the role of the value, not the type. `customerName` beats `s` or `str`. `discountPercent` beats `d`. The method body is the only place the name is used, so spelling it out costs nothing and pays back at every call site that reads the signature.\n\nAvoid generic placeholders like `value`, `data`, `temp`, `obj`, or single letters unless the math really is generic. A method that adds two numbers can call them `a` and `b`. A method that takes a price and a quantity should not.\n\nMatch the naming convention of the rest of the codebase: camelCase, starting with a lowercase letter. Reserved words like `class`, `int`, or `return` can't be used as names. Shadowing a class field with a parameter name is allowed, but it forces the use of `this.field = field` to disambiguate.\n\n\n```java\npublic class GoodNames {\n public static void main(String[] args) {\n chargeCustomer(\"Alice\", 29.99, \"USD\");\n }\n\n static void chargeCustomer(String customerName, double amount, String currency) {\n System.out.println(\"Charging \" + customerName + \": \" + amount + \" \" + currency);\n }\n}\n```\n\n\nReading the signature alone should reveal what the method needs. That's the bar.\n\n---\n\n# Passing Primitive Values\n\nPrimitive parameters cover the small fixed set of types Java has built in: `int`, `long`, `double`, `float`, `boolean`, `char`, `byte`, `short`. When a primitive is passed as an argument, the method receives a copy of that value. The method can change its parameter variable freely, and the caller's variable stays the same.\n\n\n```java\npublic class CopyValue {\n public static void main(String[] args) {\n int stock = 10;\n decrement(stock);\n System.out.println(\"Stock in main: \" + stock);\n }\n\n static void decrement(int count) {\n count = count - 1;\n System.out.println(\"Stock in method: \" + count);\n }\n}\n```\n\n\nThe method's `count` variable holds a copy of `stock`'s value. Reassigning `count` inside the method has no effect on `stock` in `main`. That's the contract for primitives. The reasoning behind it (and how reference types compare) comes later in this section.\n\nEvery primitive parameter behaves the same way: a copy in, no observable change to the caller's variable.\n\n\n```java\npublic class FlipFlag {\n public static void main(String[] args) {\n boolean isPremium = false;\n upgrade(isPremium);\n System.out.println(\"Premium in main: \" + isPremium);\n }\n\n static void upgrade(boolean premium) {\n premium = true;\n System.out.println(\"Premium in method: \" + premium);\n }\n}\n```\n\n\nSame story for `boolean`, `char`, and the rest. The method receives a copy, edits the copy, and the original is untouched.\n\n---\n\n# Passing Reference Types\n\nStrings, arrays, and objects are reference types. When one is passed as an argument, the method receives the reference, which is the address the object lives at. The caller and the method both point at the same object.\n\nFor the purposes of this lesson, the practical question is simpler: what shows up inside the method when a `String`, an array, or an object is passed? The answer is the same thing the caller has, accessible through the parameter name.\n\n\n```java\npublic class PassString {\n public static void main(String[] args) {\n String productName = \"Wireless Mouse\";\n printLength(productName);\n }\n\n static void printLength(String name) {\n System.out.println(\"Name: \" + name);\n System.out.println(\"Length: \" + name.length());\n }\n}\n```\n\n\nThe method sees the same string the caller created, available under the local name `name`. Calling methods on it works exactly as it would from `main`.\n\nArrays follow the same usage pattern.\n\n\n```java\npublic class PrintCart {\n public static void main(String[] args) {\n String[] cart = {\"Mouse\", \"Keyboard\", \"Monitor\"};\n printCart(cart);\n }\n\n static void printCart(String[] items) {\n System.out.println(\"Items in cart: \" + items.length);\n for (int i = 0; i < items.length; i++) {\n System.out.println(\" \" + (i + 1) + \". \" + items[i]);\n }\n }\n}\n```\n\n\nThe parameter `items` lets the method work with the same array the caller has. Anything possible with an array in `main` works the same way inside the method, through the parameter name.\n\nWhat actually happens internally when a reference is passed, and whether changes to the object's contents are visible to the caller, comes later in this section. For now, the usage-level takeaway is enough: hand over the variable, the method gets to use it.\n\n---\n\n# Type Matching and Implicit Widening\n\nThe compiler checks every argument against its parameter's type before the call is allowed. If the types match exactly, the call goes through. If they don't, Java applies the same widening rules used in assignments: a smaller numeric type can flow into a larger one without a cast.\n\n\n```java\npublic class WideningArgs {\n public static void main(String[] args) {\n int quantity = 3;\n printAsDouble(quantity);\n printAsDouble(29.99);\n }\n\n static void printAsDouble(double value) {\n System.out.println(\"Value: \" + value);\n }\n}\n```\n\n\nThe first call passes an `int`. The parameter wants a `double`. Java widens the `int` to a `double` on the way in, so `3` becomes `3.0` inside the method. The same rule applies for `byte` to `int`, `short` to `long`, `float` to `double`, and so on. The relevant point here is that the same widening conversions Java applies in assignments happen automatically at call sites too.\n\n\n```mermaid\nflowchart LR\n Call[\"printAsDouble(quantity)
quantity = 3 (int)\"]:::cyan --> Widen[\"int widened to double
3 becomes 3.0\"]:::orange\n Widen --> Param[\"Parameter 'value' (double)
receives 3.0\"]:::green\n Param --> Body[\"Method body uses 'value'\"]:::teal\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe diagram shows the path an `int` argument takes when the parameter type is `double`: the value gets widened on the way in, the parameter receives the widened version, and the method body works with the wider type.\n\nNarrowing the other direction does not happen on its own. Passing a `double` to a parameter declared as `int` is a compile error.\n\n\n```java\npublic class NarrowingFails {\n public static void main(String[] args) {\n double price = 29.99;\n addToCart(price); // does not compile\n }\n\n static void addToCart(int amount) {\n System.out.println(\"Adding: \" + amount);\n }\n}\n```\n\n\nThe compiler rejects this with:\n\n\n```shell\nerror: incompatible types: possible lossy conversion from double to int\n addToCart(price);\n ^\n```\n\n\nThe fix is to make the narrowing explicit with a cast, the same way an assignment would.\n\n\n```java\npublic class NarrowingCast {\n public static void main(String[] args) {\n double price = 29.99;\n addToCart((int) price);\n }\n\n static void addToCart(int amount) {\n System.out.println(\"Adding: \" + amount);\n }\n}\n```\n\n\nThe cast truncates `29.99` to `29` before the method sees it. The point of forcing the cast is the same as everywhere else Java requires it: narrowing can lose information, and the language wants that acknowledged explicitly.\n\nThe same rules apply to references in a looser form. A parameter declared as `String` only accepts a `String` argument (or `null`). A parameter declared as a supertype accepts any subtype, which becomes relevant once inheritance enters the picture.\n\n---\n\n# Parameter Validation\n\nA method has no control over what the caller passes in. A method that calculates a discount might receive a negative percentage. A method that looks up a product by index might receive a negative index. Without guards, the method either produces wrong output silently or crashes with a confusing error that points inside the method rather than at the bad input.\n\nParameter validation is the practice of checking inputs at the top of the method and rejecting the bad ones immediately, with a clear error.\n\n\n```java\npublic class DiscountValidation {\n public static void main(String[] args) {\n applyDiscount(100.0, 20.0);\n applyDiscount(100.0, -5.0);\n }\n\n static void applyDiscount(double price, double percent) {\n if (percent < 0 || percent > 100) {\n throw new IllegalArgumentException(\n \"Discount percent must be between 0 and 100, got: \" + percent);\n }\n double finalPrice = price - (price * percent / 100.0);\n System.out.println(\"Final price: $\" + finalPrice);\n }\n}\n```\n\n\nThe good call goes through. The bad one fails with a message that names the problem and the offending value. `IllegalArgumentException` is Java's standard exception for \"this input is not acceptable\". For now, treat `throw new IllegalArgumentException(...)` as a way to reject bad input and surface a clear error at the call site.\n\nCommon things to validate, depending on the method:\n\n\n| Input kind | What to check |\n| ---------- | ------------- |\n| Number | Range, sign, finite (no `NaN`, no infinity for `double`) |\n| `String` | Null, empty, length within bounds, expected format |\n| Array or list | Null, non-empty if required, length within bounds |\n| Index | `0 <= index < length` |\n| Reference object | Null when null isn't acceptable |\n\n\nThe null check is the one beginners skip most often, and it bites the hardest because the resulting `NullPointerException` doesn't always point at the right line.\n\n\n```java\npublic class NullCheck {\n public static void main(String[] args) {\n printGreeting(\"Alice\");\n printGreeting(null);\n }\n\n static void printGreeting(String customerName) {\n if (customerName == null) {\n throw new IllegalArgumentException(\"customerName must not be null\");\n }\n System.out.println(\"Hello, \" + customerName.toUpperCase());\n }\n}\n```\n\n\nWithout the check, the second call would still fail, but with a `NullPointerException` from inside `toUpperCase`. The validated version fails earlier, with a message that names the parameter and the problem. That difference is the whole reason to validate.\n\nFor methods that take many parameters, `Objects.requireNonNull` keeps the checks compact. It's a utility method that throws `NullPointerException` when its argument is null and returns the value otherwise.\n\n\n```java\nimport java.util.Objects;\n\npublic class RequireNonNull {\n public static void main(String[] args) {\n chargeCustomer(\"Alice\", \"USD\");\n }\n\n static void chargeCustomer(String customerName, String currency) {\n Objects.requireNonNull(customerName, \"customerName\");\n Objects.requireNonNull(currency, \"currency\");\n System.out.println(\"Charging \" + customerName + \" in \" + currency);\n }\n}\n```\n\n\nIf either argument were null, the exception would name the parameter that failed the check, so the caller doesn't have to guess which input was bad.\n\nValidate at the top of the method, before any real work runs. A failed check short-circuits the method cleanly. Mixing validation with logic makes both harder to read.\n\n---\n\n# Final Parameters\n\nA parameter can be marked `final`, which means the method body is not allowed to reassign it.\n\n\n```java\npublic class FinalParam {\n public static void main(String[] args) {\n printDiscount(100.0, 20.0);\n }\n\n static void printDiscount(final double price, final double percent) {\n // price = 200.0; // would not compile: cannot assign a value to final variable price\n double off = price * percent / 100.0;\n System.out.println(\"Discount: $\" + off);\n }\n}\n```\n\n\n`final` on a parameter doesn't change what the caller sees. It only constrains what the method body can do with its own parameter variable. Some teams adopt `final` on all parameters by default as a style choice, the idea being that reassigning a parameter inside a method is usually a sign of muddled logic. Other teams skip it for readability. Both are reasonable.\n\n`final` parameters are useful in lambdas and anonymous inner classes. A lambda that uses a method's parameter requires that parameter to be `final` or \"effectively final\", meaning unchanged after assignment. Writing `final` explicitly makes the intent obvious. Until lambdas show up, the strict requirement won't appear, but the keyword is useful to know now.\n\n\n```java\npublic class FinalReassignFails {\n public static void main(String[] args) {\n increment(5);\n }\n\n static void increment(final int count) {\n count = count + 1; // compile error\n System.out.println(count);\n }\n}\n```\n\n\nThe compiler rejects this with:\n\n\n```shell\nerror: cannot assign a value to final variable count\n count = count + 1;\n ^\n```\n\n\nWithout `final`, the same code compiles and runs. Adding `final` is the difference between \"the parameter is a starting value that can be adjusted\" and \"the parameter is the value, and this name will not point at anything else\".\n\n---\n\n# A Mental Model of the Call\n\nPutting the pieces together, consider the path an argument travels during a method call.\n\n\n```mermaid\nflowchart LR\n A[Argument at call site
e.g., 29.99]:::cyan --> B[Type check
Compatible? Widen if needed.]:::orange\n B --> C[Parameter slot
e.g., 'double amount']:::green\n C --> D[Local variable inside method
Method uses 'amount']:::teal\n D --> E[Return or end of method
'amount' goes out of scope]:::red\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe compiler matches the argument's type against the parameter's type. If the call is legal, the value flows into the parameter slot. Inside the method, the parameter is a normal local variable, named whatever the signature says. When the method ends, that local variable goes out of scope, just like any other local.\n\nFor primitives, what gets handed across is a copy of the value. For reference types, what gets handed across is a copy of the reference, both names now pointing at the same object. The Pass by Value lesson at the end of this section unpacks exactly what that means for code that tries to mutate parameters.","pageType":"java"}

Method Parameters

Get Premium