skip to content

What is the `entries` property on a Kotlin enum class, and how does it differ from the older `values()` function?

level: juniorimportance: must knowfreq 70%

answer

  1. entries = property, List, immutable, cached
  2. values() = function, Array, fresh copy each call
  3. Stable since Kotlin 1.9
  4. Same declaration order
  5. entries[i], for-in, map/filter all work

basics

~10 s

entries gives you all the constants of an enum as a read-only list. The old values() did the same but returned an array, and it made a brand-new copy every time you called it.

solid answer

~30 s

Every Kotlin `enum class` exposes a synthetic `values()` function and a `valueOf()` function. `values()` returns an `Array<E>` and allocates a fresh defensive copy on each call (arrays are mutable, so it must). Kotlin 1.9 stabilized `EnumClass.entries`, a property of type `EnumEntries<E>`, which is an immutable `List<E>`. Because it's immutable, the runtime returns the same cached instance every time — no per-call allocation. You iterate it with normal collection operations (`map`, `filter`, `indexOf`, `size`). Prefer `entries` for read-only iteration; it's the idiomatic modern replacement. `values()` still exists for compatibility and when you genuinely need a mutable array.

code

kotlin · 7 lines
kotlin
enum class Direction { NORTH, EAST, SOUTH, WEST }

fun firstChars(): List<Char> =
    Direction.entries.map { it.name.first() }   // no array allocation

fun asArray(): Array<Direction> =
    Direction.values()                          // fresh Array<Direction> each call

go deeper

for a junior

Knows entries is the modern read-only list replacing values() and uses it in a for-loop.

for a middle

Explains the array-vs-list and mutable-vs-immutable distinction and the per-call allocation of values().

for a senior

Notes the Kotlin 1.9 stabilization, EnumEntries<E>: List<E>, caching, and when an array is still required.

for a principal

Frames it as an API-design win (immutability enabling caching) and weighs migration/compat across multiplatform targets.

## What an enum class gives you A Kotlin `enum class` is a class with a fixed, finite set of named instances (constants), e.g. `Color.RED`, `Color.GREEN`. The compiler generates a few members automatically. ## `values()` — the legacy way `values()` is a synthetic static-like function returning an `Array<Color>` of all constants in declaration order. - An **array** in Kotlin/JVM is mutable — you can overwrite `arr[0]`. To prevent one caller from corrupting shared state, `values()` must hand back a **fresh defensive copy** on every call. - That means iterating `values()` in a hot loop allocates a new array each time → avoidable garbage. ## `entries` — the modern way (stable since Kotlin 1.9) `entries` is a **property** (not a function — no parentheses) of type `EnumEntries<Color>`, which **implements `List<Color>`**. - It is **immutable** (read-only), so the runtime can safely return one **cached, shared** instance — **zero per-call allocation**. - You get the full `List` API: `size`, `indexOf`, `first()`, `map { }`, `filter { }`, indexing `entries[0]`, and `for (c in Color.entries)`. - Order is the declaration order, identical to `values()`. ```kotlin enum class Color { RED, GREEN, BLUE } fun main() { // modern, allocation-free, returns a List for (c in Color.entries) println(c) val names: List<String> = Color.entries.map { it.name } // legacy, allocates a fresh Array each call val arr: Array<Color> = Color.values() } ``` ## When to still use `values()` - You truly need a mutable `Array<Color>` (e.g. to pass to a Java API expecting one). - Code targeting Kotlin < 1.9. ## Related members - `valueOf("RED")` looks a constant up by name (throws `IllegalArgumentException` if absent). - `.name` and `.ordinal` are properties on each constant. **Rule of thumb:** for read-only iteration/lookup, use `Color.entries`; reach for `values()` only when an array is required.

  • Why can `entries` be cached but `values()` cannot?
    `entries` is an immutable `List` so sharing one instance is safe; `values()` returns a mutable array that a caller could overwrite, so each call needs a defensive copy.
  • Is `entries` a function or a property?
    A property — you write `Color.entries`, no parentheses.

values() photocopies the class roster for you every time you ask; entries hands you the one laminated copy pinned to the wall.

saying these in an interview costs you the question

  • Calling it `entries()` with parentheses (it's a property).
  • Claiming `entries` returns an array.
  • Saying `values()` and `entries` differ in iteration order.
  • Thinking `entries` is mutable / you can add to it.
  • Believing `values()` caches its result.

context

resolving links…