skip to content

Java Getters/Setters As Properties

3 roadmaps5 questions

Kotlin exposes Java getX/setX pairs as synthetic properties, so obj.x works while obj.getX() still compiles. Interviewers ask when this does not apply — a getter with no matching pattern stays a method.

part ofKotlinoverview, primer and where to startread it →
on this pageshow

explore

questions

5

When you call a Java class from Kotlin, how do you read a value exposed by a Java getter like getName()? Show both ways Kotlin lets you access it.

level: juniorimportance: must knowfreq 80%

answer

  1. getX() -> property x
  2. setX() makes it assignable
  3. both obj.name and obj.getName() work
  4. JavaBeans convention
  5. same bytecode, Kotlin-only sugar

basics

~10 s

Kotlin lets you write obj.name instead of obj.getName(). It turns Java get/set methods into a property you read and write with a dot. You can still call obj.getName() the old way too.

solid answer

~30 s

Kotlin recognizes the JavaBeans naming convention and exposes Java getX()/setX() pairs as a synthetic property x. So Java's person.getName() becomes person.name in Kotlin, and a setName(String) lets you assign person.name = "Ann". The original methods aren't removed: getName() stays callable as a normal method, so both person.name and person.getName() work and compile to the same getName() bytecode call. The property is read-only (a val-like) if only a getter exists, and read-write (var-like) if a matching setter exists. This is a compile-time convenience in Kotlin only; the Java class is unchanged and has no Kotlin property.

code

kotlin · 5 lines
kotlin
// Java: class User { private String email; public String getEmail(){return email;} public void setEmail(String e){email=e;} }
val u = User()
u.email = "[email protected]"      // setEmail(...)
println(u.email)          // getEmail()
println(u.getEmail())     // still allowed

go deeper

for a junior

Knows obj.name reads getName() and that both syntaxes work.

for a middle

Explains read-only vs read-write depends on setter presence; same bytecode.

for a senior

Frames it as compile-time JavaBeans mapping local to Kotlin's view; notes method form stays valid.

for a principal

Discusses how this shapes API ergonomics when consuming Java libs and that it doesn't alter the Java class contract.

## What's happening Kotlin and Java handle 'properties' differently. Java traditionally uses **getter/setter methods** following the **JavaBeans convention**: a field `name` is read via `getName()` and written via `setName(String)`. Kotlin has first-class **properties** accessed with a dot: `obj.name`. When Kotlin calls Java code, the compiler **maps** Java getter/setter methods onto Kotlin's property syntax. This is called a **synthetic property** — it exists only in Kotlin's view of the Java class. ## The mapping rules - A method `getX()` (no params, non-void return) becomes a readable property `x`. - A matching `setX(value)` (one param, returns void) makes that property **assignable**. - A boolean accessor named `isX()` maps to property `x` as well (see the dedicated `is`-prefix rule). ```kotlin // Java: class Person { String getName(){...} void setName(String n){...} } val p = Person() val n = p.name // calls getName() p.name = "Ann" // calls setName("Ann") // The methods are STILL there: val n2 = p.getName() // also legal p.setName("Bob") // also legal ``` ## Key facts - **Both forms compile to the same bytecode** — `p.name` is just sugar for `p.getName()`. - If only `getName()` exists, the property is **read-only**; assigning to it is a compile error. - This only applies to **Java** classes seen from Kotlin. A Kotlin-defined property already IS a property. - The synthetic property only kicks in for the JavaBeans shape: `getX()`/`isX()`/`setX()`. A method like `fetchName()` stays a plain method.

  • If the Java class only has getName() and no setName(), what happens when you write p.name = "x"?
    Compile error: the synthetic property is read-only (val-like), so it can't be assigned.

Like a nickname: 'name' is a shorthand the compiler accepts for the longer 'getName()' — same person, friendlier to say.

saying these in an interview costs you the question

  • Claiming Kotlin removes/hides getName() so you can only use the property form
  • Thinking the property exists in the Java class itself
  • Saying obj.name does something different at runtime than obj.getName()
  • Believing assignment works even without a setter

context

resolving links…

open as a page

A Java class has a method `boolean isEnabled()` and `void setEnabled(boolean)`. What does the synthetic Kotlin property look like, and what's special about the `is` prefix rule?

level: middleimportance: should knowfreq 55%

basics

~10 s

Kotlin sees it as a property called enabled — but wait, no: for is-prefixed getters Kotlin keeps the whole name. The property is isEnabled, accessed as obj.isEnabled, and set via setEnabled.

open as a page

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%

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.

open as a page

From Kotlin you extend a Java class that has getValue()/setValue(). How can you override the accessor behavior, and what are the rules for overriding a Java getter as a Kotlin property vs. a function?

level: seniorimportance: should knowfreq 30%

basics

~20 s

In Kotlin you can override the inherited Java accessor pair as a property — declare override var value and supply custom get()/set(). You may also still override the raw methods, but using the property form is the idiomatic way.

open as a page

What subtle pitfalls arise from Kotlin's synthetic-property mapping when consuming Java APIs — e.g. ambiguous names, the get/is collision, and how does this interact with the reverse (Kotlin properties seen from Java)?

level: principalimportance: nice to knowfreq 20%

basics

~20 s

Pitfalls include both getName() and isName() existing (ambiguity), names like getURL decapitalizing oddly, and confusion when going the other way: Kotlin properties appear to Java as getX()/setX() methods, so Java callers never see a 'property'.

open as a page