value class con @JvmInline: qué genera realmente el compilador

La declaración cabe en una línea y esa brevedad engaña, porque debajo de ella ocurre algo cualitativamente distinto de lo que hace cualquier otra palabra clave del lenguaje. Una data class genera métodos que uno podría haber escrito a mano. Un object genera un patrón que existía antes que el lenguaje. Una clase de valor, en cambio, altera la representación: le dice al compilador que ese tipo existe durante la comprobación estática y que debe desaparecer al emitir el código, sustituido en cada punto posible por el único campo que contiene. Es la primera construcción del lenguaje que se compromete explícitamente con lo que no habrá en el resultado, y entender qué genera exige mirar el bytecode, porque el código fuente no lo cuenta.

La declaración y su traducción

El punto de partida es una declaración mínima. La anotación no es decorativa: en el objetivo JVM el compilador la exige, porque las plataformas de Kotlin no comparten la misma estrategia de representación y la anotación deja constancia de que se ha elegido la de la JVM de forma explícita.

@JvmInline
value class IdCuenta(val valor: Long)

fun cargar(id: IdCuenta): String = "cuenta " + id.valor

fun main() {
    val id = IdCuenta(42L)
    println(cargar(id))
}

Lo que el compilador emite para esto no contiene ninguna asignación de memoria. La función cargar recibe un Long, la variable local id es un Long, y la llamada pasa un Long. El tipo IdCuenta ha existido durante todo el análisis, ha rechazado cualquier intento de pasarle un identificador de otra entidad, y luego se ha evaporado. Aproximadamente esto es lo que se vería si se decompilase el resultado a Java.

// aproximacion de lo generado
public static final String cargar_TC7ZOTs(long valor) {
    return "cuenta " + valor;
}

public static final void main() {
    long id = IdCuenta.constructor_impl(42L);
    System.out.println(cargar_TC7ZOTs(id));
}

Hay dos detalles que merecen atención. El primero es que la clase IdCuenta sí existe en el resultado como clase real, con métodos estáticos que implementan el constructor, la igualdad, el código de dispersión y la representación textual. Existe porque hace falta un lugar donde vivan esos comportamientos y porque, como veremos en la lección siguiente, hay situaciones en las que el envoltorio reaparece y entonces se necesita un objeto de verdad. Lo que desaparece es la instancia en el uso normal, no la declaración.

El segundo detalle es el sufijo del nombre de la función. Ese apéndice ilegible es el mangling, y resuelve un problema que sin él sería insalvable.

Por qué el nombre viene deformado

Supón dos funciones que en Kotlin son claramente distintas y que, tras el aplanamiento, tendrían la misma firma en la JVM.

@JvmInline value class IdCuenta(val valor: Long)
@JvmInline value class IdPedido(val valor: Long)

fun buscar(id: IdCuenta): String = "..."
fun buscar(id: IdPedido): String = "..."

Si el compilador emitiese las dos como un método que recibe un Long, la clase resultante tendría dos métodos con idéntica firma, lo cual el formato de clase de la JVM prohíbe. La solución es añadir al nombre un sufijo derivado de un hash de la firma original en Kotlin, de modo que los dos métodos generados tengan nombres distintos y la ambigüedad desaparezca en el nivel donde importa. El mangling tiene además un efecto deliberado sobre la interoperabilidad: llamar a esa función desde Java resulta incómodo por accidente, lo cual es una forma honesta de señalar que la garantía de tipos que la función asume no se puede sostener desde el otro lado de la frontera. Cuando se quiere ofrecer una función con clases de valor a consumidores de Java, la práctica correcta es exponer una fachada explícita.

@JvmInline value class Centimos(val valor: Long)

fun aplicarDescuento(importe: Centimos): Centimos = Centimos(importe.valor * 9 / 10)

@JvmName("aplicarDescuentoJava")
fun aplicarDescuentoParaJava(importeEnCentimos: Long): Long =
    aplicarDescuento(Centimos(importeEnCentimos)).valor

flowchart TD
A[Codigo fuente con value class] --> B[Fase de analisis]
B --> C[El tipo existe y rechaza mezclas]
C --> D[Fase de generacion]
D --> E{El uso admite representacion plana}
E -->|Si| F[Se emite el campo desnudo y se deforma el nombre]
E -->|No| G[Se emite una instancia real de la clase]

Las restricciones son consecuencias

El constructo impone una lista de reglas que resulta mucho más fácil de recordar si se deriva cada una de la representación elegida en lugar de aprenderla de memoria.

Un único campo, declarado en el constructor primario y necesariamente inmutable. Es la restricción fundamental y la razón es aritmética: la representación aplanada consiste en sustituir el envoltorio por su contenido, y eso solo tiene sentido si el contenido es una cosa. Dos campos exigirían pasar dos argumentos donde la firma declara uno, que es precisamente el problema que resuelven los tipos de valor auténticos del proyecto Valhalla y que las clases de valor de Kotlin no intentan abordar. La inmutabilidad viene del mismo sitio: si el envoltorio no existe en tiempo de ejecución, no hay ningún lugar donde escribir.

Sin herencia en ninguna de las dos direcciones. La clase no puede heredar de otra ni ser heredada, y por tanto es implícitamente final. Una jerarquía requiere despacho dinámico, el despacho dinámico requiere una cabecera de objeto donde consultar el tipo, y una cabecera de objeto es exactamente lo que aquí no hay. Sí puede implementar interfaces, pero con una consecuencia que la lección siguiente examina en detalle.

Sin campos con estado más allá del propio valor. Se pueden declarar propiedades, siempre que sean calculadas a partir del campo y no tengan campo de respaldo; se pueden declarar funciones miembro, bloques de inicialización y un companion object. Lo que no cabe es guardar nada adicional, porque no hay dónde.

@JvmInline
value class Correo(val texto: String) {

    init {
        require("@" in texto) { "correo invalido" }
    }

    val dominio: String get() = texto.substringAfter('@')   // calculada: sin campo

    fun enmascarar(): String = texto.first() + "***@" + dominio

    companion object {
        fun deConfianza(t: String): Correo? = if ("@" in t) Correo(t) else null
    }
}

Conviene añadir una regla que no se deduce de la representación sino de la interoperabilidad: el nombre del campo importa. Como la clase generada expone métodos estáticos construidos alrededor de ese nombre y la propiedad de acceso se genera a partir de él, cambiarlo es un cambio incompatible en la interfaz binaria aunque el tipo siga siendo el mismo. En una biblioteca publicada eso significa que el nombre del único campo forma parte del contrato público con la misma seriedad que el nombre de la clase, algo que sorprende a quien está acostumbrado a tratar los campos privados como detalle interno.

@JvmInline value class Milisegundos(val valor: Long)

// renombrar el campo a "ms" rompe a los consumidores ya compilados
// aunque el codigo fuente que los produjo siga compilando sin cambios

El bloque init merece un comentario aparte porque es la puerta de entrada a los tipos con invariante. La validación se ejecuta en la construcción, lo cual significa que la existencia de un valor de tipo Correo es prueba de que el texto pasó la comprobación. Esa es una propiedad enorme y se obtiene sin ningún objeto en el montón, aunque conviene recordar que el envoltorio no impide construir un valor inválido por vías que esquiven el constructor, como la deserialización mediante reflexión.