Strengthening Immutability in Kotlin. A Glimpse into Valhalla

Immutability is a powerful tool for making code safer, easier to reason about, and more concurrency-friendly, but adopting it often comes with trade-offs. Kotlin embraces immutability in its design, yet there is a lot of untapped potential to make it even stronger.

In this session, we will start by digging into Kotlin's current approach: what the language already offers, where the gaps are, and the reasons behind its choices. We'll then venture into Project Valhalla, an upcoming JVM initiative that brings value types and new memory models, offering exciting ways to make immutability cheaper and more practical for Kotlin developers.

Finally, we'll look further ahead. What could a more powerful immutability story for Kotlin look like? How could it fit naturally with features like smart casts, coroutines, and the pragmatic spirit of the language? We'll explore ideas and possibilities for taking immutability to the next level without sacrificing the things that make Kotlin so developer-friendly.

If you're curious about how Kotlin and the JVM are setting the stage for a safer, faster future, and how immutability could play a starring role then this talk is for you.

Transcript

1. Strengthening Immutability in Kotlin A Glimpse into Valhalla @antonarhipov
2. What is this talk about? New immutability features coming to Kotlin: (deeply) immutable value classes, checked and enforced by the compiler copy vars as a way to ergonomically update immutable data
3. What is immutability? Why is immutability? Where is immutability?
4. What is immutability?
5. Immutability is when something cannot be changed
6. Immutability is when something cannot be changed
7. Something is . data class Person(val name: String, val age: Int) fun test() { val me = Person("Anton", 21) me.age = 22 } a proper t y in a (data) class
8. Something is . fun test() { val bestKotlinVersions = listOf("1.3.72", "1.9.25", "2.0.0") bestKotlinVersions.add("3.0.0") } a collection from a standard library
9. Something is . Any entity in your programming language - an inter f ace - a type parameter - a proper t y - an anonymous object literal
10. Something is . Any entity in your programming language - an inter f ace - a type parameter - a proper t y - an anonymous object literal Controlled manually by the developer not making mistakes Automatically by compiler enforcing proper use
11. What does cannot be changed mean?
12. What does cannot be changed mean? The physical state cannot be changed Also known as concrete state Informally, your "bits-and-by t es" are frozen No matter how you view the concrete state, the observable results will always stay the same Example: raw by t e array, java.lang.String
13. What does cannot be changed mean? The physical state cannot be changed Also known as concrete state Informally, your "bits-and-by t es" are frozen No matter how you view the concrete state, the observable results will always stay the same Example: raw by t e array, java.lang.String
14. cannot be changed also means . The logical state cannot be changed Also known as abstract state Informally, your observable state is fixed Your concrete state can change, but it is impossible to observe from the outside Example: skip lists, splay trees
15. The logical state cannot be changed Also known as abstract state Informally, your observable state is fixed Your concrete state can change, but it is impossible to observe from the outside Example: skip lists, splay trees cannot be changed also means .
16. cannot be changed also means .
17. Immutability is when something cannot be changed
18. Where is immutability? (In Kotlin)
19. Kotlin suppor t s simple pragmatic immutability
20. Effective Java. Item 17
21. Effective Java. Item 17 Minimize mutability • Don't provide methods that modify object's state • Ensure that the class can't be extended • Make all fields final • Make all fields private • Ensure exclusive access to any mutable components
22. Don't provide mutators data class Point(val x: Int, val y: Int) / / no mutators provided to change x or y Prefer using immutable data to mutable. Always declare local variables and proper t ies as val rather than var if they are not modified after initialization
23. Make all fields private In Kotlin, a field is only used as a par t of proper t y to hold its value in memory. Fields cannot be declared directly. However, when a proper t y needs a backing field, Kotlin provides it class UserGroup(val members: List<User>) { // .... val admins: List<User> = members.filter { it.isAdmin } }
24. Make all fields private In Kotlin, a field is only used as a par t of proper t y to hold its value in memory. Fields cannot be declared directly. However, when a proper t y needs a backing field, Kotlin provides it class UserGroup(val members: List<User>) { // .... val admins: List<User> = members.filter { it.isAdmin } } This is not a field This is not a field either
25. Ensure exclusive access to any mutable state class UserCache() { private val users: MutableMap<String, User> = mutableMapOf() val currentUsers: Collection<User> get() = users.values val frozenCurrentUsers: Collection<User> get() = users.values.toList() }
26. Ensure exclusive access to any mutable state class UserCache() { private val users: MutableMap<String, User> = mutableMapOf() val currentUsers: Collection<User> get() = users.values val frozenCurrentUsers: Collection<User> get() = users.values.toList() } mutable collection as read-only view mutable collection defensively copied
27. Effective Java. Item 17 Minimize mutability Don't provide methods that modify object's state Ensure that the class can't be extended Make all fields final Make all fields private Ensure exclusive access to any mutable components
28. Why is immutability?
29. Effective Java. Item 17 Immutable classes are easier to design, implement, and use than mutable • Immutable objects are simple • Immutable objects are inherently thread-safe • Not only can you share immutable objects, but they can share their internals • Immutable objects make great building blocks for other objects • Immutable objects provide failure atomicity for free
30. UI programming Caching What else?
31. Jetpack Compose • Declarative / reactive approach to UI • Informally, "takes the C out of MVC" - Views are updated automatically when your Models change • For some input (app state), remembers the output (the rendered UI) - Skips recomposition if input did not change This means you need to track the state changes
32. data class Contact(val name: String, val address: Address) data class Address(var street: String, var zipCode: String) @Composable fun Home( ... ) { ContactList( . .. ) { ContactDetails( ... , contact, .. . ) } } Stability in Compose Do I need to recompose this?
33. data class Contact(val name: String, val address: Address) data class Address(var street: String, var zipCode: String) @Composable fun Home( ... ) { ContactList( . .. ) { ContactDetails( ... , contact, .. . ) } } Stability in Compose Tracking changes in mutable data is hard Compose compiler repor t s:
34. data class Contact(val name: String, val address: Address) data class Address(val street: String, val zipCode: String) @Composable fun Home( ... ) { ContactList( . .. ) { ContactDetails( ... , contact, .. . ) } } Stability in Compose Compose compiler repor t s:
35. Compose best practices
36. Caching • Also known as memoization • The most well-known way of "space-time tradeoff" • For some input (parameters), remembers the output (the computed result) - Avoids recomputation if input did not change Looks very similar to UI programming!
37. Caching data class Book(var title: String, var isbn: ISBN) class LibraryRepository { val books: ImmutableList<Book> get() = apiCache.get(Path.BOOKS) }
38. data class Book(var title: String, var isbn: ISBN) class LibraryRepository { val books: ImmutableList<Book> get() = apiCache.get(Path.BOOKS) } Caching fun egoisticClient() { //... val books = LibraryRepository().books books.forEach { it.title = capitalize(it.title) } //... The cache is now invalid
39. data class Book(val title: String, val isbn: ISBN) class LibraryRepository { val books: ImmutableList<Book> get() = apiCache.get(Path.BOOKS) } Caching fun egoisticClient() { //... val books = LibraryRepository().books val fixedBooks = books.map { it.copy(title = capitalize(it.title)) } //... The cache is still valid
40. Caching cares about outputs •For some input (your arguments), remembers the output (your computed result) - Avoids recomputation if input did not change •Also needs outputs to not change - Otherwise you can corrupt your cache This means you need to return immutable data
41. (better) immutability
42. better immutability simple immutability
43. What is missing?
44. Immutable something data class Contact(val name: String, val address: Address) data class Address(var street: String, var zipCode: String) •We have immutable references (vals), enforced by the compiler •We do not have immutable values, enforced by the compier - Neither immutable instances - Nor immutable types
45. Immutable types data class Contact(val name: String, val address: Address) data class Address(val street: String, val zipCode: String) What restrictions should immutable types have? •Shallow immutability? - All stored (concrete) proper t ies are vals •Deep immutability - All stored (concrete) proper t ies are vals - All stored (concrete) proper t ies are of deeply immutable types
46. Immutable types data class Contact(val name: String, val address: Address) data class Address(val street: String, val zipCode: String) What restrictions should immutable types have? •Shallow immutability? - All stored (concrete) proper t ies are vals •Deep immutability - All stored (concrete) proper t ies are vals - All stored (concrete) proper t ies are of deeply immutable types The compiler can check concrete state automatically
47. Immutable types data class Contact(val name: String, val address: Address) data class Address(val street: String, val zipCode: String) No matter how you view the concrete state, the observable state will always be the same, right?
48. Immutable types data class Contact(val name: String, val address: Address) data class Address(val street: String, val zipCode: String) val a = Address("Gelrestraat 16", "1079 MZ") val b = Address("Gelrestraat 16", "1079 MZ") println(a == b) // Yay! println(a === b) // Oops ... Identity leaks the mutability box
49. What is missing? • The ability to declare (deeply) immutable types - Which are checked and enforced by the compiler • These immutable types should not rely on identity - For immutable data, only data matters We need better value types
51. Inline value types @JvmInline value class ZipCode(val value: String) Kotlin already has restricted value types (a.k.a inline types) - No identity - All stored (concrete) proper t ies are vals - Only one preper t y is allowed - Only shallow immutability
52. Inline value types @JvmInline value class ZipCode(val value: String) Inlined when possible - But it is first and foremost an optimization
53. Immutable value types immutable value class Contact(val name: String, val address: Address) value class Book(val title: String, val isbn: ISBN) Kotlin is getting (deeply) immutable value classes with multiple proper t ies
54. Immutable value types immutable value class Contact(val name: String, val address: Address) value class Book(val title: String, val isbn: ISBN) - You can have more than one val-s in your value classes - You can mark a value class as immutable making it deeply immutable - Other restrictions are the same as for inline value types - They are not inlined! Kotlin is getting (deeply) immutable value classes with multiple proper t ies
55. Deeply immutable value types immutable value class ContactList(val contacts: List<Contact>) // Error immutable value class Contact(val name: String, val address: Address) // Error value class Address(val street: String, val zipCode: String) Checking for deep immutability requires more suppor t
56. Deeply immutable value types immutable value class ContactList(val contacts: List<Contact>) // Error immutable value class Contact(val name: String, val address: Address) // Error value class Address(val street: String, val zipCode: String) - We know about (deep) immutability of value types - Value class is shallow immutable, immutable value class is deeply immutable - What about regular (reference) types? For example, List Checking for deep immutability requires more suppor t
57. Immutable reference types immutable value class ContactList(val contacts: ImmutableList<Contact>) If you can about deeply immutable reference types, you can use some inherent knowledge - Example: knowledge about kotlinx.collections.immutable - But you need to remember to use the correct immutable types
58. @Immutable reference types @Immutable public interface ImmutableList<out E> : List<E>, ImmutableCollection<E> Kotlin is getting @Immutable annotation to mark deeply immutable reference types - Kotlin compiler uses it as a contract
59. Immutability and generics @Immutable public interface ImmutableList<out E> : List<E>, ImmutableCollection<E> val contacts: ImmutableList<Contact> = fetchContacts() // OK val immMatrix: ImmutableList<MutableList<Int >> = emptyMatrix() // Not OK Generic immutable types are conditionally immutable Their immutability depends on how they are initialized
60. Immutable generics @Immutable public interface ImmutableList<out E> : List<E>, ImmutableCollection<E> public fun <immutable E> immutableListOf(vararg elements: E): ImmutableList<E> public fun <immutable T : Any?> mutableStateOf(value: T, …): MutableState<T> Kotlin will track generics of deeply immutable types Type parameters marked as immutable are checked to be deeply immutable on instantionation
61. (Deeply) immutable value types with multiple proper t ies
62. data class Book(var title: String, var isbn: ISBN) class LibraryRepository { val books: ImmutableList<Book> get() = apiCache.get(Path.BOOKS) } fun immutableClient() { val books = LibraryRepository().books val fixedBooks = books.map { it.copy(title = capitalize(it.title)) } }
63. The "copy" ladder fun immutableClient() { //... val fixedBooks = books.map { it.copy( title = capitalize(it.title), isbn = it.isbn.copy(eanPrefix = 979), publisher = it.publisher.copy( address = it.publisher.address.copy( //... ) ) ) }
64. The "copy" ladder fun immutableClient() { //... val fixedBooks = books.map { it.copy( title = capitalize(it.title), isbn = it.isbn.copy(eanPrefix = 979), publisher = it.publisher.copy( address = it.publisher.address.copy( //... ) ) ) }
65. Maybe take the 'elevator' instead? fun immutableClient() { val books = LibraryRepository().books // ... val fixedBooks = books.map { it.title = capitalize(it.title) it.isbn.eanPrefix = 979 it.publisher.address.zipCode = //... it } //... }
66. Maybe take the 'elevator' instead? fun immutableClient() { val books = LibraryRepository().books // ... val fixedBooks = books.map { it.title = capitalize(it.title) it.isbn.eanPrefix = 979 it.publisher.address.zipCode = //... it } //... } Kotlin compiler could take a copy ladder for us
67. "The elevator" fun immutableClient() { val books = LibraryRepository().books // ... val fixedBooks = books.map { // copy var fixedBook copy var fixedBook = it fixedBook.title = capitalize(fixedBook.title) fixedBook.isbn.eanPrefix = 979 fixedBook.publisher.address.zipCode = " ... " fixedBook } //... }
68. copy var-s immutable value class Book(copy var title: String, copy var isbn: ISBN) copy var book = books.first { ... } book.title = capitalize(book.title) book.isbn.eanPrefix = 979
69. copy var-s copy var book = books.first { ... } book = book.withTitle(capitalize(book.title)) book = book.withIsbn(book.isbn.withEanPrefix(979)) immutable value class Book(copy var title: String, copy var isbn: ISBN) copy var book = books.first { ... } book.title = capitalize(book.title) book.isbn.eanPrefix = 979
70. copy var-s copy var book = books.first { ... } book = book.with$Aggregated( title = capitalize(book.title), isbn = book.isbn.withEanPrefix(979) ) Kotlin compiler could optimize extra allocations for temporary objects - If we do not do this, we keep the same number of allocations as with manually controlled immutable data classes - If we do this then get less allocations
71. copy var-s for ergonomic updates of immutable data
72. Multiple updates
73. Multiple updates
74. Multiple updates
75. Multiple updates "in-place"
76. Multiple updates "in-place"
77. Work in progress Do we need value inter f aces?
78. Work in progress Do we need value inter f aces? How value types are captured by lambdas?
79. Work in progress Do we need value inter f aces? How value types are captured by lambdas? Are immutable value arrays a thing or not?
80. Work in progress Do we need value inter f aces? How value types are captured by lambdas? Are immutable value arrays a thing or not? Do we need copy funs with custom return types?
81. Work in progress Do we need value inter f aces? How value types are captured by lambdas? Are immutable value arrays a thing or not? Do we need copy funs with custom return types? Do we need copy var function parameters?
82. Work in progress Do we need value inter f aces? How value types are captured by lambdas? Are immutable value arrays a thing or not? Do we need copy funs with custom return types? Do we need copy var function parameters? Do we need copy functional types?
83. What about project Valhalla?
84. JEP 401 Value classes on the JVM platform Two main goals: - Provide types which opt-out identity - Suppor t run-time optimizations of these types
85. JEP 401 value classes JEP 401 value class == shallow immutable type This is the basic building block for immutability in Kotlin, to which we add ◦ Deep immutability ◦ Ergonomic updates of immutable data ◦ Better suppor t across other language features
86. It is about immutability Once we get the UX with immutability right, we can think about adding optimizations If you care about optimizations first, please reach out! -> KT-77734 Immutability of data, thatʼs our main goal Optimizations for are a nice bonus. When Valhalla comes out we get the optimization for free
87. Immutability and smar t casts
88. Immutability and smar t casts Smart casts are allowed to be safely performed on objects that are immutable
89. Immutability and smar t casts Smart casts are allowed to be safely performed on objects that are immutable Pair comes from another module, we do not support smart casts for such types
90. Immutability and smar t casts Value types cannot be changed concurrently It is safe to propagate the smart cast knowledge in more cases
91. Recap (deeply) immutable value types with multiple proper t ies copy vars / funs for ergonomic updates of immutable data better smart casts safer concurrency something else? KT-77734
92. Credits: Marat Akhin
93. speakerdeck.com/antonarhipov kotlinlang.org youtrack.jetbrains.com/issue/KT-77734