Since Kotlin doesn't allow you to directly declare constants inside a class like static members in Java, we have a couple of options on how to do it in Kotlin. My question is, what are the performance costs of each option, and which one is cheaper? I don't want to know which one is more readable or considered best-practice, I only want it from a performance perspective.
Option 1: Use a companion object
So a code that looks like this:
class Thing {
companion object {
const val TAG = "Thing"
}
...
}
In Java looks like this:
public final class Thing {
public static final String TAG = "Thing";
public static final Thing.Companion Companion = new Thing.Companion((DefaultConstructorMarker)null);
public static final class Companion {
private Companion() {
}
public Companion(DefaultConstructorMarker $constructor_marker) {
this();
}
}
...
}
It creates this inner class Companion and instantiates it. How costly is this?
Option 2: Declare it as a top-level variable
So this:
const val TAG = "Thing"
class Thing {
...
}
Becomes this:
public final class ThingKt {
public static final String TAG = "Thing";
}
public final class Thing { ... }
It creates a new class with a static member. How different is this than using an object to store it?
Option 3: Use an external object
Like so:
object ThingConstants {
const val TAG = "Thing"
}
class Thing { ... }
Which in Java looks like this:
public final class ThingConstants {
public static final String TAG = "Thing";
public static final ThingConstants INSTANCE;
... // Private constructor
}
public final class Thing { ... }
So similar to declaring as top-level, except the created class has an INSTANCE field that is initialized in a private constructor. How costlier is this compared to using a top-level variable?
Option 4: Drop the const modifier
So you just use the good old val:
class Thing {
val TAG = "Thing"
...
}
This is a mystery to me. It doesn't create any additional classes, but doesn't reap the benefits of the const modifier either. This means each instance of the class is going to have its own instance of TAG, as well as generating getters and setters for it too, right? But I also read that the JVM optimizes it as a constant. So there is more to this option than I initially thought.
