No se puede insertar bytecode JVM 1.8 en 1.6: analizando bajo el capó

Introducción: Cuando el compilador dice «no»

¿Alguna vez ha visto esa aterradora línea roja en la consola? Cannot inline bytecode built with JVM target 1.8 into bytecode that is being built with JVM target 1.6. Si es así, no está solo. Este error ha acumulado miles de visitas en Stack Overflow y se ha convertido en una verdadera piedra de tropiezo para los desarrolladores de Kotlin. Pero, ¿y si le dijera que detrás de este mensaje no solo hay un error, sino toda una historia de evolución de la máquina virtual de Java?

En este artículo no solo mostraremos cómo solucionar el error. Miraremos bajo el capó del compilador de Kotlin, entenderemos qué es JVM target, cómo funcionan las funciones inline y por qué el bytecode de la versión 1.8 no quiere ser amigo de la versión 1.6. Abróchense los cinturones: será interesante. Y sí, escribiremos en Kotlin, porque no solo está de moda, sino que es terriblemente conveniente.

¿Qué es JVM target y por qué es importante?

Para empezar, aclaremos los conceptos básicos. JVM (Java Virtual Machine) es el entorno en el que se ejecuta su código Kotlin. Cada versión de JVM puede entender el bytecode de una versión específica. Por ejemplo:

• JVM target 1.6 — bytecode compatible con Java 6. Es una versión antigua pero estable.
• JVM target 1.8 — bytecode para Java 8. Añade soporte para lambdas, Stream API, nuevas anotaciones y otras características.

Cuando escribe kotlin { jvmTarget = "1.8" } en build.gradle.kts, le está diciendo al compilador: «Genera bytecode que JVM 1.8 entenderá». Y si especifica "1.6", el bytecode será compatible con versiones más antiguas.

El problema surge cuando diferentes partes de su proyecto (o bibliotecas) están compiladas para diferentes JVM target. El compilador de Kotlin ve la discrepancia y entra en pánico. Esto afecta especialmente a las funciones inline, que en Kotlin son una poderosa herramienta de optimización.

Funciones inline: ¿cómo funcionan bajo el capó?

En Kotlin, la palabra clave inline obliga al compilador a insertar el código de la función directamente en el lugar de la llamada. Esto difiere de las funciones normales, donde la llamada se realiza a través de la pila. Las funciones inline aceleran la ejecución (especialmente con lambdas), pero crean un problema: el bytecode de la función se copia en cada llamada.

Imagine que tiene una biblioteca compilada con JVM target 1.8. Dentro de ella, hay una función inline que utiliza invokedynamic (una instrucción que apareció en Java 7/8 para lambdas). Usted enlaza esta biblioteca a un proyecto con JVM target 1.6. El compilador intenta insertar el bytecode con invokedynamic en un contexto donde dicha instrucción no existe. Y obtiene un error.

// Ejemplo de función inline en una biblioteca (compilada con target 1.8)inline fun performAction(action: () -> Unit) {    println("Before")    action()    println("After")}

// Su código (compilado con target 1.6)fun main() {    performAction { println("Hello!") } // ERROR: Cannot inline bytecode...}

El compilador grita: «¡Oye, no puedo copiar este bytecode, usa características de JVM 1.8, pero yo tengo target 1.6!»

¿Por qué ocurre esto en proyectos reales?

La causa más común es un conflicto de versiones en las dependencias de Gradle. Por ejemplo:

• Usted utiliza la biblioteca Kotlin coroutines (que se compila con target 1.8)
• Su proyecto está configurado con target 1.6 (quizás debido a una plantilla obsoleta o requisitos de compatibilidad)
• Al compilar, Kotlin intenta insertar el bytecode de las corrutinas y se encuentra con la incompatibilidad

Otra situación son las llamadas directas a funciones inline desde diferentes módulos. Si el módulo A se compila con target 1.8 y el módulo B con target 1.6, y usted llama a una función inline desde A en B, el error está garantizado.

Cómo se ve en la práctica: análisis de un ejemplo

Vamos a simular la situación. Crearemos un proyecto simple en Kotlin con Gradle.

// build.gr