Los objetivos de compilación: JVM, Native, Wasm y JS

Kotlin es uno de los pocos lenguajes de propósito general que compila a una máquina virtual con recolector de basura, a código máquina nativo, a JavaScript y a WebAssembly, con la misma sintaxis y sin dialectos. Eso no es un detalle de implementación: es una restricción permanente sobre lo que el lenguaje puede prometer. Todo lo que la biblioteca estándar común contiene, y sobre todo lo que no contiene, se explica por esta arquitectura.

Un frontend, varios backends

Desde la 2.0 el compilador tiene una forma limpia. El frontend K2 hace todo lo que depende del lenguaje y de nada más: analiza la sintaxis, resuelve nombres, infiere tipos y emite diagnósticos. Su resultado es una representación semántica unificada, independiente de la plataforma. Después, un traductor convierte esa representación en la representación intermedia compartida, y a partir de ahí cada backend genera lo suyo.

flowchart TD
A[Codigo fuente Kotlin] --> B[Frontend K2: nombres, tipos, diagnosticos]
B --> C[Representacion intermedia comun]
C --> D[Backend JVM: bytecode]
C --> E[Backend Native: LLVM]
C --> F[Backend JS: modulos ES]
C --> G[Backend Wasm: WasmGC]
style B fill:#a6e3a1,color:#11111b
style C fill:#89b4fa,color:#11111b

La importancia de esta forma es política además de técnica. Con un frontend único, una característica nueva del lenguaje se especifica y se comprueba una sola vez; antes de K2 había que reimplementar el análisis por objetivo, y eso hacía que los objetivos jóvenes fueran siempre ciudadanos de segunda.

Qué comparten de verdad

Lo compartido es más de lo que suele suponerse y menos de lo que a veces se promete.

La sintaxis y la semántica del lenguaje son idénticas. No hay directivas de preprocesador ni variantes por plataforma. Las clases de datos, las clases selladas, las funciones de extensión, las funciones inline, los delegados de propiedad y las corrutinas existen exactamente igual en los cuatro sitios.

La biblioteca estándar común ofrece el núcleo verdaderamente portátil: colecciones, secuencias, texto, matemáticas, tiempo con Duration, resultados con Result, y las primitivas de las corrutinas. Lo que está en el paquete común está garantizado en todos los objetivos.

El mecanismo expect y actual cubre el resto. En el código común declaras la forma sin cuerpo y en cada objetivo aportas la implementación. Es una abstracción resuelta en tiempo de compilación, no en ejecución: no hay despacho dinámico ni coste asociado.

// en el conjunto de fuentes común
expect fun identificadorDeDispositivo(): String

// en el conjunto de fuentes de JVM
actual fun identificadorDeDispositivo(): String =
    System.getProperty("os.name") ?: "desconocido"

Los conjuntos de fuentes se organizan además de forma jerárquica, lo que permite compartir código entre subconjuntos de objetivos —por ejemplo entre todos los nativos de Apple— sin duplicarlo ni bajarlo al mínimo común denominador:

src/
  commonMain/      # lo que vale en los cuatro objetivos
  jvmMain/         # bytecode: acceso a todo el ecosistema Java
  appleMain/       # compartido entre iOS, macOS y watchOS
    iosMain/
    macosMain/
  jsMain/
  wasmJsMain/

Esa jerarquía es la diferencia entre un proyecto multiplataforma sano y uno que degenera. Sin ella, cualquier cosa que no valga en los cuatro objetivos hay que repetirla en cada uno; con ella, el código compartido entre los tres sistemas de Apple se escribe una sola vez y sigue viendo la interoperabilidad nativa.

Qué no pueden compartir

Aquí empieza la parte honesta, y es donde se pierde tiempo si no se entiende pronto.

El modelo de memoria. La JVM tiene un recolector generacional maduro; Wasm delega en el recolector del anfitrión; JavaScript usa el del motor; y Kotlin/Native tiene el suyo propio, un recolector con trazado que desde 2022 sustituyó al modelo anterior de congelación de objetos. Aquel modelo antiguo exigía marcar los objetos compartidos entre hilos como inmutables y fue, con diferencia, la mayor fuente de fricción en la historia del soporte multiplataforma. Su retirada es la razón de que hoy el código concurrente común se parezca al de la JVM.

La concurrencia observable. Las corrutinas son comunes, pero los despachadores no. En JavaScript y en Wasm dentro del navegador no hay hilos reales en el sentido clásico: hay un bucle de eventos. El código común que asume paralelismo verdadero funciona en JVM y en Native, y se degrada en el navegador. Por eso lo idiomático es escribir contra la abstracción de suspensión y dejar la elección del despachador en la frontera de la plataforma.

// común: solo suspende, no decide dónde se ejecuta
suspend fun sincronizar(repo: Repositorio) = withContext(dispatcherDeIO) {
    repo.descargar()
}

// declarado en común, resuelto por objetivo
expect val dispatcherDeIO: CoroutineDispatcher

La reflexión. Es completa en la JVM y deliberadamente mínima fuera de ella, porque conservarla entera impediría eliminar código muerto y dispararía el tamaño del binario. Esta es la causa de que el ecosistema Kotlin haya empujado tanto hacia los complementos de compilador: la serialización resuelve en tiempo de compilación lo que en Java se resolvía leyendo anotaciones en ejecución. La restricción de una plataforma acabó produciendo una solución mejor para todas.

La interoperabilidad. Cada objetivo mira hacia un ecosistema distinto: Java, C y Objective-C, JavaScript, y el anfitrión de Wasm. Ese código de frontera nunca es común por definición.

Cómo esa asimetría condiciona el diseño

Lo interesante es que estas restricciones no se quedan en la biblioteca: se filtran hacia arriba y se convierten en características del lenguaje. Cuatro ejemplos concretos, todos rastreables hasta la necesidad de sobrevivir en varios objetivos.

Las clases de valor. La JVM no tiene tipos de valor de usuario, así que Kotlin introdujo las clases envolventes que el compilador elimina en línea cuando puede. Es una solución de compilador precisamente porque no podía apoyarse en una capacidad de la plataforma que solo algunas tienen.

Las funciones inline con parámetros reificados. Nacen del borrado de tipos de la JVM, pero su semántica se definió de forma que funcione igual en Native y en JavaScript, donde el problema original ni siquiera existe. Lo que empezó como parche se convirtió en característica uniforme.

La suspensión en lugar del paralelismo. Ya se ha dicho, y es la decisión más importante: la especificación de las corrutinas habla de suspender y reanudar, nunca de hilos. Esa formulación es la que permite el mismo código en un servidor con cientos de núcleos y en una pestaña de navegador con un solo bucle de eventos.

Los complementos de compilador como mecanismo de extensión. Cuando el lenguaje rechaza las macros y varias plataformas rechazan la reflexión, la única vía que queda para generar código es un complemento que actúe sobre la representación intermedia. Por eso la serialización, la inyección de dependencias y la persistencia se han movido en Kotlin hacia esa vía, y por eso K2 tuvo que estabilizar también la interfaz para esos complementos antes de considerarse terminado.