Cómo se compila tu Kotlin

Llevas veintiocho niveles escribiendo Kotlin y razonando dentro de Kotlin, y eso ha sido correcto porque el lenguaje está diseñado para que su modelo mental se sostenga solo. Pero debajo hay una máquina que no conoce las funciones de nivel superior, ni las propiedades, ni los argumentos por defecto, ni los objetos singleton, y a la que hay que explicárselo todo con un vocabulario pobre de clases, campos y métodos. Esa traducción no es un detalle de implementación que puedas ignorar para siempre: determina los nombres que verá un consumidor Java, define la superficie de tu API binaria, decide qué cambios rompen la compatibilidad al publicar una biblioteca y explica buena parte de los mensajes de error más desconcertantes que vas a leer en tu carrera. Este nivel entero consiste en mirar tu propio código desde el otro lado del cristal.

Los nombres que no escribiste

La JVM solo sabe cargar clases. Todo lo que declares tiene que acabar dentro de una, y cuando tu código no proporciona ninguna, el compilador la inventa. La regla básica es mecánica: un archivo Utiles.kt con declaraciones de nivel superior produce una clase llamada UtilesKt, y cada función y propiedad de ese archivo se convierte en un miembro public static final de esa clase.

// Utiles.kt
package app.texto

fun normalizar(s: String): String = s.trim().lowercase()
val VERSION = "3.1"

Visto desde Java, eso no es un paquete con funciones sueltas, porque tal cosa no existe: es app.texto.UtilesKt.normalizar(...) y app.texto.UtilesKt.getVERSION(). El nombre UtilesKt es ahora parte de tu API pública, con todo lo que eso implica: si renombras el archivo, rompes la compatibilidad binaria de cualquier consumidor Java sin tocar una sola línea de lógica.

Las clases anidadas siguen la convención de la propia JVM, con el signo del dólar como separador entre el contenedor y lo contenido, mientras que las construcciones anónimas y locales reciben un contador. Conviene tener el diccionario entero a la vista.

El caso del acompañante merece una parada, porque es la fuente número uno de sorpresa para quien llega desde Java. Los miembros de un companion object no son estáticos: viven en la clase anidada Companion, de modo que desde Java se invocan como Configuracion.Companion.crear(). Eso no es un accidente sino la consecuencia directa de que en Kotlin el acompañante es un objeto de verdad, con identidad, capaz de implementar interfaces y de recibir extensiones. La forma estática de toda la vida existe, pero hay que pedirla, y esa petición es el tema de la lección siguiente.

Los métodos que aparecen solos

Un buen número de funcionalidades del lenguaje no tienen contrapartida en la JVM y se sostienen sobre métodos que tú no escribiste. Reconocerlos convierte un volcado de bytecode ilegible en un texto perfectamente narrativo.

Las propiedades son el caso más frecuente y el más invisible: un val nombre: String es un campo privado más un método getNombre, y un var añade setNombre. Los argumentos por defecto son el segundo, y su traducción es ingeniosa. La JVM no tiene valores por defecto, así que el compilador emite el método real y a su lado un puente sintético con un parámetro adicional de máscara de bits que indica qué argumentos venían y cuáles hay que rellenar.

fun conectar(host: String, puerto: Int = 443, tls: Boolean = true) { }

// Lo que existe realmente en el .class
public static final void conectar(String host, int puerto, boolean tls) { }
public static void conectar$default(String host, int puerto, boolean tls, int mascara, Object marca) { }

Ese conectar$default es sintético y no forma parte de tu API pública: un consumidor Java está obligado a pasar los tres argumentos, y de ahí nace la anotación que estudiaremos después. La misma familia de trucos aparece en varios frentes más.

flowchart TD
K[Codigo Kotlin] --> A[Propiedad]
K --> B[Argumentos por defecto]
K --> C[Miembro internal]
K --> D[When sobre enum]
K --> E[Interfaz con cuerpo]
A --> A1[Campo privado mas getter y setter]
B --> B1[Metodo dolar default con mascara de bits]
C --> C1[Publico con nombre alterado por modulo]
D --> D1[Clase sintetica WhenMappings con tabla de enteros]
E --> E1[Metodo por defecto mas clase DefaultImpls]
style B1 fill:#f9e2af,color:#11111b
style C1 fill:#f38ba8,color:#11111b

El caso de internal es especialmente traicionero. La JVM no tiene un concepto de módulo compatible con el de Kotlin, así que un miembro internal se compila como público y su nombre se altera añadiendo el del módulo, algo como procesar$mi_modulo. La consecuencia práctica es doble: desde Java ese miembro es perfectamente invocable, con lo cual internal no es una barrera de seguridad sino una convención verificada por el compilador Kotlin; y como el nombre del módulo forma parte del nombre binario, renombrar el módulo rompe la compatibilidad de cualquier código ya compilado contra él.

Quedan los métodos puente, que la JVM impone a cualquier lenguaje con genéricos y retornos covariantes. Su origen es el borrado de tipos: si una clase concreta especializa un parámetro de tipo, la firma que hereda y la que implementa no coinciden en el bytecode, y hace falta un intermediario que reciba la primera, convierta y delegue en la segunda.

interface Caja<T> {
    fun leer(): T
}

class CajaDeTexto : Caja<String> {
    override fun leer(): String = "hola"
}

// Dos metodos donde tu escribiste uno
public String leer() { return "hola"; }
public synthetic bridge Object leer() { return this.leer(); }

A esa familia se suman las clases sintéticas de apoyo: la tabla WhenMappings, que traduce constantes de enumeración a enteros consecutivos para permitir un salto de tabla en lugar de una cadena de comparaciones, y la clase DefaultImpls, que aloja los cuerpos de los métodos de interfaz.

Abrir el fichero y mirarlo

Todo lo anterior es verificable en menos de un minuto, y esa verificación debería ser un reflejo antes que una curiosidad. La herramienta mínima viene con el JDK.

kotlinc Utiles.kt -d salida/
javap -p -c salida/app/texto/UtilesKt.class
javap -p -v salida/app/texto/UtilesKt.class | head -40

La bandera de miembros privados es imprescindible, porque casi todo lo interesante es sintético o privado y sin ella no aparece. El modo detallado muestra además el conjunto de constantes, las tablas de excepciones y las anotaciones de nulabilidad que Kotlin escribe en las firmas para que las herramientas de Java las aprovechen. Dentro del IDE, la ruta equivalente es mostrar el bytecode de Kotlin y pulsar el botón de decompilar, que produce el Java aproximadamente equivalente: es menos fiel que el bytecode, pero infinitamente más rápido de leer y suficiente para el noventa por ciento de las preguntas.

# El nivel de bytecode y la version de Java se eligen explicitamente
kotlinc -jvm-target 21 Utiles.kt -d salida/

Esa elección es independiente del JDK con el que compiles y del que usarás en producción, y su efecto es real: determina si el compilador puede emitir métodos por defecto en interfaces, qué familia de concatenación de cadenas se usa y qué constructos modernos de la plataforma están disponibles. Kotlin 2.4 amplió el rango soportado hasta Java 26, de modo que hoy el compilador cubre desde objetivos muy conservadores hasta lo último publicado, y el criterio para elegir ya no es lo que el compilador aguanta sino lo que tu despliegue garantiza.