skip to content

Which Java methods do NOT become synthetic Kotlin properties? Give the rules that disqualify a method, and what happens with getter/setter type mismatches.

level: middleimportance: should knowfreq 45%

answer

  1. getter: no params, non-void
  2. setter: one param, void
  3. wrong prefix (fetch/compute) -> method only
  4. type mismatch -> read-only property
  5. parameterized getX(i) -> not a property

basics

~20 s

Only methods shaped exactly like JavaBeans accessors become properties. A getter with parameters, a void/Unit getter, or a wrong name (like fetchName) stays a plain method. If getter and setter types disagree, you only get a read-only property.

solid answer

~40 s

Kotlin synthesizes a property only for accessors matching the JavaBeans shape: a getter `getX()`/`isX()` with **no parameters and a non-Unit return**, optionally paired with `setX(value)` taking **one parameter and returning void/Unit**. Disqualifiers: a 'getter' that takes arguments (e.g. `getItem(int)`), a void-returning 'getter', or a name not starting with `get`/`is` (e.g. `fetchName()`, `computeTotal()`) — all stay callable only as methods. If `getX()` returns `String` but `setX(int)` takes `Int`, the **types don't agree**, so Kotlin exposes a **read-only** property `x` (the getter) and the mismatched setter remains a regular method. Static getters/setters on a Java class are also not exposed as instance synthetic properties.

go deeper

for a junior

Knows fetchName() must be called as a method, not obj.name.

for a middle

States the param/return rules and that a type mismatch yields a read-only property.

for a senior

Explains the mapping is syntactic, handles overloads, and predicts surface shape for API review.

for a principal

Considers naming guidelines so a Java API consumed from Kotlin presents the intended property/method surface.

## The strict JavaBeans shape Kotlin's synthetic-property mapping is **purely syntactic** — it recognizes accessor *shapes*, not intent. A method qualifies as a **getter** when ALL hold: - name is `getSomething` or `isSomething`, - takes **zero parameters**, - returns a **non-`void`** type (and for the `is` rule, `Boolean`). A method qualifies as the paired **setter** when: - name is `setSomething`, - takes **exactly one parameter**, - returns `void` (Unit). ## What gets disqualified ```kotlin // Java methods and how Kotlin sees them: // String getName() -> property `name` (read-only or read-write) // String getItem(int i) -> NOT a property (has a param); call getItem(i) // void getStuff() -> NOT a property (void return) // String fetchName() -> NOT a property (wrong prefix); call fetchName() // String computeTotal() -> NOT a property; plain method ``` These non-conforming methods are still perfectly callable — they just never appear as `obj.x`. ## Type mismatch between getter and setter If the getter and setter **types don't match**, Kotlin cannot form a read-write property: ```kotlin // Java: int getValue() / void setValue(String s) val v: Int = obj.value // OK: read-only property from getValue() // obj.value = "x" // ERROR: setter type differs; not part of property obj.setValue("x") // call the setter as a normal method ``` The getter wins as the property; the incompatible setter stays a method. ## Overloaded getters If there are overloads like `getName()` and `getName(Locale)`, only the zero-arg `getName()` participates as the property; the overload is a method. ## Why know this Reviewers and API designers must predict whether a Java method surfaces as `obj.x` or must be called `obj.getX(...)`. Misjudging it produces confusing 'why isn't this a property' moments, especially with builder-style or parameterized accessors.

  • Java has String getName() and an overload getName(Locale l). Can you write obj.name?
    Yes — the zero-arg getName() backs the property `name`; the overload getName(Locale) remains a regular method.
  • Does a Java static getStatus() become a property accessed as ClassName.status?
    No — static accessors aren't exposed as synthetic instance properties; you call the method (or via the companion/class as a static).

saying these in an interview costs you the question

  • Thinking any method starting with get becomes a property regardless of parameters
  • Assuming a type-mismatched getter/setter still forms a read-write property
  • Believing fetchX()/computeX() get property treatment
  • Not realizing a void-returning getX() is disqualified

context

resolving links…