# Understanding Kotlin property finality and compiler-opened classes

DevFeed: [Understanding Kotlin property finality and compiler-opened classes](<https://devfeed.tech/articles/the-modifier-that-shouldn-t-be-there-25894.md>)

Original publisher: [Read original article](<https://proandroiddev.com/the-modifier-that-shouldnt-be-there-77ff941f0529?source=rss-1331e67af4e1------2>)

Author: Danny Preussler

Published: 2021-05-31T14:15:00Z

Content type: tutorial

Language: en

Sources: [Stories by Danny Preussler on Medium](<https://devfeed.tech/sources/stories-by-danny-preussler-on-medium.md>)

Topics: [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Android Studio](<https://devfeed.tech/topics/android-studio.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [Testing](<https://devfeed.tech/topics/testing.md>)

Tags: [android-studio](<https://devfeed.tech/tags/android-studio.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [java](<https://devfeed.tech/tags/java.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [programming](<https://devfeed.tech/tags/programming.md>), [testing](<https://devfeed.tech/tags/testing.md>)

## AI overview

This article explains when Kotlin properties are final or open, including why properties inherited from interfaces may be open by default. It also shows how a Kotlin compiler plugin used for mocking can make classes and their fields open, and suggests alternatives such as Mockito's inline mock maker and using fewer mocks.

## Source excerpt

The Kotlin modifier that shouldn't be therePhoto by Belinda Fewings on Unsplash Most Kotlin developers would agree that a val property is equivalent to a final property in Java. What if I tell you that this is not completely true and sometimes you might need a final val? Opposite to Java, Kotlin properties are final by default unless they are explicitly marked as open! This would mean there is no need for the final keyword, right? Let's Google that: As the internet confirmed our hypothesis, I was quite surprised when Android Studio told me to addfinal to a val: and indeed adding final would fix that: So there is a final keyword for properties but why and when should we make a val final? Let's look at this behavior using a simple example: class FinalBlog { val someProperty: String = "some" init { print(someProperty + "thing") } } "Everything works as expected here and the code will print "something" when the class is instantiated. Let's modify everything to be open: open class FinalBlog { open val someProperty: String = "some" init { print(someProperty + "thing") } } This will trigger the same type of warning I got before. This is very obvious when you think about it. The class can be subclassed and our property might be overridden. This could lead to unexpected side effects (which we will look into at the end of this post.). We can fix this simply by removing theopen modifier from the field. So, althought the warning has the same cause, it's not the exact same scenario my Android Studio was warning me on, there is no way I could add final here: non open already means final! Let's try something else: interface BlogTopic { val someProperty: String } open class FinalBlog: BlogTopic { override val someProperty: String = "some" init { print(someProperty + "thing") } } If the property is inherited from an interface, then it's open by default! Again, we will get the warning, we were looking for: And this time adding the final modifier will fix it: open class FinalBlog: Blo