The not-so-obvious Kotlin. Field annotations and modifiers.

Recently I’ve taken the Kotlin for Java developers course developed by JetBrains. It’s an excellent course for Java devs that want to know all about Kotlin’s features, and they make a really great job at explaining things. However, I’ve felt that some points could have been explored more as they’re not really obvious for people that are transitioning from Java. I’m going to pinpoint these things and do my best at explaining these in a series of articles. These articles will not go in into explaining concepts that are straightforward and easy to grasp, so don’t expect a detailed explanation of Kotlin here, but no advanced stuff here either.

The first point that I want to cover is fields and variables. How can you declare a static field vs a regular field? How would you declare a compile-time constant? What if you don’t want getters and setters to be generated? What is inlining? I’ll try to answer these questions below.

Generating the right field types in Kotlin is all about using the correct mix of annotations and modifiers. Let’s look at the annotations first:

Instructs the Kotlin compiler not to generate getters/setters for this property and expose it as a field.

Getters and setters will be automatically generated for each field of your class. This might not obvious because in Kotlin we usually reference the fields as if they’re public — whereas “under the hood” a getter and setter will be called each time.

@JvmField is also obscure because it will produce a static or a regular field depending on where you put it in Kotlin. There are two cases:

  1. You annotate a field in a plain old class and you get a regular field just without any getter or setter as explained above.
  2. You annotate a field in an object or a companion object and you will get a static field.

Let’s see this in action. Let’s build a class Car:

class Car {
val wheels = "wheels"
val windows = "windows"

object Engine {
val oil = "oil"
val valves = "valves"

companion object {
val transmission = "transmission"
val lights = "lights"

Here’s how we would access each of the properties of this class in Java:

Car car = new Car();

With @JvmField

// no getter / setter generated for the field

// static field is generated for the inner static class

// static field generated for companion object

Without @JvmField

//getter / setter generated

// accessed via the instance + getter generated

// accessed via the companion object instance + getter generated

Specifies that an additional static method needs to be generated from this element if it’s a function. If this element is a property, additional static getter/setter methods should be generated.

You’re probably going to use this annotation rarely, as this might provide value only in case you’re interacting with Java in your code. However, it’s worth knowing about this one.

Kotlin doesn’t have static functions, so whenever you declare a companion object and want to call the enclosing function from Java — you would need to make a similar call:


which is a bit cumbersome. Now if you annotate someMethod() with @JvmStatic — the compiler will generate static methods which would allow you to call the function just like a regular static function from Java:


At first, it seems that there is no point in using const modifier if we have val, right? But there is an optimization going on under the hood in the case of const val, something called inlining. Suppose you have some Kotlin code like this:

const val path = "myComputer/coding"
class PathFinder {
fun getAbsPath(): String {
return "$path + /someOtherDirectory"

If we decompile this to bytecode and compile it back in Java (here’s a good article on how to do that in case you want to try), we should get something like this:

class PathFinder {
public String getAbsPath() {
return "myComputer/coding/someOtherDirectory"

As you can see this can make an important optimization difference if getAbsPath() is referenced often. So, even though you can use val everywhere instead of const — it’s important to know what optimization const brings.

Another not-so-obvious thing about Kotlin would be the fact that everything about the property has to/can be specified inside the primary constructor unless you have some custom logic further down of course. It’s convenient once you get used to it, but not really obvious in the beginning in my opinion. Let’s see this in our Car class.

Adding a parameter to the primary constructor without any modifiers doesn’t create any properties as expected:

class Car(airbag: String)

So we can’t access it in any way unless we do some initialization in the init {} block. Now let’s add a var modifier:

class Car(var airbag: String)

Now we can do this in Java:


And now let’s add @JvmField annotation:

class Car(@JvmField var airbag: String)

As expected, we get this on the Java side:


Same thing for overriding a field. You can specify it in the constructor

interface Vehicle  {
val wheelCount: Int
class Car(override val wheelCount: Int) : Vehicle {}


Kotlin annotations and their mix with the modifiers were a bit vague for me in terms of what they create on the Java side at first. Because Kotlin is such a powerful and concise language I think it’s important to understand what’s going on when we apply certain annotations and modifiers.

That’s pretty much it in terms of what I wanted to cover on this topic. I hope I helped you get a clearer picture of this matter. Stay tuned for further articles on Kotlin’s non-obvious parts.

Did I miss something or got something wrong? Let me know in the comments.

Software engineer. Learning everyday and trying to share my knowledge in the process. Into mobile development, computer science and the brain.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store