Java vs Kotlin no es solo sintaxis: mantenibilidad, equipos y deuda técnica

En un artículo anterior ya cubrí la comparativa técnica entre Java y Kotlin: data classes, null safety, coroutines, extensiones. Las diferencias de sintaxis son reales y están bien documentadas en cualquier tutorial. Pero la realidad es que cuando llevas unos años manteniendo proyectos con ambos lenguajes, las decisiones que más pesan no son las de sintaxis. Son las de equipo, mantenimiento y deuda técnica.

Este artículo no repite la comparativa de features. Parte de un punto distinto: ya sabes que Kotlin es más conciso, que tiene null safety y que comparte la JVM con Java. La pregunta es qué pasa cuando eso se encuentra con un equipo de seis personas, un proyecto que lleva tres años en producción y una base de código que crece cada sprint.

La curva de aprendizaje que nadie te cuenta

La curva de aprendizaje de Kotlin para un desarrollador Java se suele presentar como suave. Y es verdad que escribir tu primer data class o tu primer when es intuitivo. Pero la curva real no es la de escribir Kotlin básico. Es la de escribir Kotlin idiomático, entender código Kotlin escrito por otros, y navegar una base de código que mezcla ambos lenguajes.

Lo que cuesta de verdad

• Funciones de extensión. Un dev Java que lee myList.filterNotNull().groupBy { it.category } necesita entender no solo qué hace, sino dónde están definidas esas funciones y si alguna es custom del proyecto.
• Scope functions. let, run, apply, also, with. Cada una tiene un caso de uso, pero en la práctica la gente las mezcla, abusa de ellas, y el código se vuelve opaco.
• Coroutines. Para alguien que viene de threads Java o CompletableFuture, las coroutines no son difíciles conceptualmente, pero el modelo de concurrencia estructurada requiere tiempo para dominarlo sin crear bugs sutiles.
• Inferencia de tipos. Kotlin infiere mucho. Eso es cómodo al escribir, pero a veces dificulta la lectura cuando no queda claro qué tipo devuelve una expresión compleja.

En mi experiencia, un desarrollador Java sénior tarda unas 2-3 semanas en ser productivo en Kotlin y unos 2-3 meses en escribir Kotlin que otro kotliner revisaría sin arrugar la nariz.

La curva de aprendizaje de Kotlin no es aprender Kotlin. Es desaprender Java. Los patrones mentales de Java ---verbosidad explícita, getters/setters, null checks manuales--- no se van en una semana.

Legibilidad: conciso no siempre es más claro

Una de las ventajas más citadas de Kotlin es que necesitas menos código para hacer lo mismo. Y es cierto. Un data class en Kotlin son 3 líneas; en Java (sin records) eran 40. Pero la concisión tiene un punto de inflexión donde deja de ayudar.

Cuando Kotlin es más legible

// Kotlin: claro, directo
val activeUsers = users
    .filter { it.isActive }
    .sortedByDescending { it.lastLogin }
    .take(10)

// Java: más verboso pero igualmente claro
List<User> activeUsers = users.stream()
    .filter(User::isActive)
    .sorted(Comparator.comparing(User::getLastLogin).reversed())
    .limit(10)
    .collect(Collectors.toList());

Aquí Kotlin gana limpiamente. Menos ruido, misma intención.

Cuando Kotlin se vuelve opaco

// Kotlin: "elegante" pero difícil de seguir
val result = data?.let { raw ->
    raw.items
        .filterNotNull()
        .takeIf { it.isNotEmpty() }
        ?.groupBy { it.category }
        ?.mapValues { (_, items) ->
            items.sumOf { it.price }
        }
        ?.also { cache.store(it) }
} ?: emptyMap()

Este código es correcto, compila, y usa features idiomáticas de Kotlin. Pero pregúntale a un desarrollador que no lo escribió qué hace exactamente. Va a necesitar un minuto para seguir la cadena de let, takeIf, also y el operador elvis. En un code review, este código genera preguntas.

El equivalente en Java sería más largo, pero cada paso sería explícito. Y la explicitud, en mantenimiento a largo plazo, tiene un valor que se subestima.

Mi regla personal

Si una expresión Kotlin necesita más de 5 segundos para que alguien del equipo entienda qué hace, probablemente vale la pena escribirla de forma más explícita. La concisión es una herramienta, no un objetivo.

Null safety en la práctica: más allá de la feature

El sistema de tipos nullable de Kotlin es, en mi opinión, su mejor feature. Obliga a pensar en nulos en tiempo de compilación en vez de descubrirlos en producción. Pero su impacto real depende de cómo se use.

Lo bueno: NullPointerExceptions que no llegan a producción

En un proyecto Java que mantengo, el top 3 de bugs en producción son NullPointerExceptions. En el equivalente Kotlin, los NPE son prácticamente inexistentes. No porque el código sea perfecto, sino porque el compilador te obliga a manejar cada caso nulo antes de compilar.

// El compilador no te deja ignorar el nulo
fun getOrderTotal(order: Order?): BigDecimal {
    // Esto no compila:
    // return order.total

    // Tienes que ser explícito:
    return order?.total ?: BigDecimal.ZERO
}

Lo malo: el abuso del operador !!

El operador !! (non-null assertion) existe para los casos donde tú sabes que un valor no es nulo pero el compilador no puede verificarlo. En la práctica, se convierte en una válvula de escape que elimina la garantía del null safety.

// Esto es básicamente volver a Java
val name = user!!.name!!.uppercase()
// Si user o name son null, NPE en runtime. Igual que Java.

He visto codebases de Kotlin con cientos de !!. A esas alturas, el null safety es decorativo. Si permites !! sin restricción en tu equipo, estás pagando el coste de Kotlin sin obtener su mayor beneficio.

El caso problemático: interoperabilidad con Java

Cuando tu código Kotlin llama a una librería Java, los tipos que vuelven son “platform types” ---ni nullable ni non-null. El compilador no te avisa. Si la librería Java devuelve null donde no esperas, tu código Kotlin explota igual que Java.

// Una librería Java que devuelve String (platform type)
val result = javaLibrary.getResult()
// result es String! (platform type), no String ni String?
// Si es null, NPE en runtime sin warning del compilador

Esto es relevante porque la mayoría de proyectos Kotlin en backend usan librerías Java. Spring Framework, Jackson, Hibernate, la propia JDK. Los platform types son la grieta por donde se cuelan los nulos que el compilador de Kotlin no puede detectar.

Ecosistema y tooling

Spring Boot: la historia de éxito

Spring Boot funciona bien con Kotlin. Hay soporte oficial, extensiones, y la comunidad es activa. Si tu stack es Spring Boot, migrar a Kotlin es viable y la experiencia es buena.

Pero “funciona bien” no significa “funciona igual”. Hay matices:

• Clases abiertas. Spring necesita que muchas clases sean abiertas para hacer proxies. Kotlin las cierra por defecto. Necesitas el plugin kotlin-spring para que las abra automáticamente.
• Data classes como entidades JPA. Hibernate necesita constructores sin argumentos. Kotlin data classes no los tienen por defecto. Necesitas el plugin kotlin-jpa.
• Anotaciones. Algunas anotaciones de Spring no se comportan igual en Kotlin. @RequestParam con valores por defecto, @Value con propiedades, etc. Son solucionables, pero son sorpresas que cuestan tiempo.

Librerías del ecosistema

La inmensa mayoría de librerías JVM son Java. Funcionan desde Kotlin, pero la experiencia no siempre es idiomática. Hay librerías Kotlin-first (Ktor, Exposed, kotlinx.serialization), pero son un ecosistema más pequeño.

Contratación: la conversación que nadie quiere tener

Este es el elefante en la habitación. Si estás decidiendo entre Java y Kotlin para un proyecto nuevo, la disponibilidad de talento importa tanto como las features del lenguaje.

La realidad del mercado

• Desarrolladores Java senior: Abundantes. Fácil encontrar. Amplio rango de experiencia.
• Desarrolladores Kotlin senior (backend): Menos. La mayoría viene de Android. Los que hacen backend Kotlin son un subconjunto más pequeño.
• Desarrolladores Java que aprenderían Kotlin: Muchos. Pero necesitan tiempo de rampeo.

He participado en procesos de selección donde el requisito era “Kotlin backend”. El pool de candidatos se reducía a una fracción comparado con “Java backend”. No porque Kotlin sea impopular, sino porque la adopción en backend es todavía menor que en Android.

El coste oculto

Cuando contratas alguien con experiencia en Java pero no en Kotlin:

• Los primeros 1-2 meses produce menos.
• El código que escribe al principio es “Java con sintaxis Kotlin” (no idiomático).
• Necesita mentoring de alguien del equipo que sí domine Kotlin.
• Los code reviews son más lentos porque el reviewer tiene que explicar patrones idiomáticos.

Esto no es un argumento en contra de Kotlin. Es un argumento a favor de incluir el coste de rampeo en la decisión.

Equipos mixtos: Java y Kotlin en el mismo proyecto

La interoperabilidad Java-Kotlin es real y funciona. Puedes tener módulos en Java y módulos en Kotlin en el mismo proyecto Gradle/Maven. IntelliJ los maneja sin problemas. Pero un proyecto mixto tiene costes que no son técnicos.

Lo que funciona

• Módulos separados por lenguaje. El módulo legacy está en Java, los módulos nuevos en Kotlin. Cada uno tiene su estilo, su compilador, sus dependencias.
• Migración gradual. Vas convirtiendo clases Java a Kotlin a medida que las tocas. IntelliJ tiene un conversor automático que, con revisión manual, funciona razonablemente bien.

Lo que genera fricción

• Dos estilos en el mismo repo. Los PRs mezclan Java y Kotlin. Los desarrolladores tienen que dominar ambos para hacer reviews.
• Convenciones divididas. ¿Las funciones utilitarias van en companion objects o en top-level functions? ¿Los DTOs nuevos son data classes o records Java? ¿Se permite !! o se rechaza en review?
• Build complexity. La compilación de un proyecto mixto Java+Kotlin es más lenta que Java puro o Kotlin puro. El compilador de Kotlin necesita analizar las clases Java y viceversa en un orden específico.

// Kotlin llamando a Java
val config = JavaLegacyConfig.getInstance() // returns Config!
// ¿Es nullable? Depende de la implementación Java.
// Kotlin no lo sabe. Tú tampoco sin leer el código Java.

// Java llamando a Kotlin
KotlinService service = new KotlinService();
String result = service.process(input);
// ¿Puede devolver null? Depende de si en Kotlin es String o String?
// Kotlin genera anotaciones @Nullable/@NotNull, pero no siempre.

Mi recomendación para equipos mixtos

1. Define una guía de estilo que cubra tanto Java como Kotlin. Qué patrones se usan en cada lenguaje, qué está prohibido, cómo se nombran las cosas.
2. No conviertas código Java que funciona solo por convertirlo. Si un módulo Java es estable, está testeado y nadie lo toca, dejarlo en Java es una decisión válida.
3. Kotlin para código nuevo, Java para mantenimiento del legacy. Es el patrón que menos fricción genera en la práctica.
4. Asegúrate de que todo el equipo puede leer ambos lenguajes. No necesitan ser expertos en los dos, pero sí poder hacer review.

Deuda técnica: la que importa no es la de sintaxis

Cuando alguien propone migrar de Java a Kotlin, el argumento suele ser “reducimos boilerplate, el código es más limpio, menos deuda técnica”. Y es parcialmente cierto. Kotlin elimina verbosidad innecesaria. Pero la deuda técnica real de un proyecto no está en los getters y setters.

La deuda técnica que importa es:

• Arquitectura mal diseñada. Un servicio God Class no mejora por reescribirlo en Kotlin.
• Falta de tests. Migrar a Kotlin sin añadir tests es cambiar el color de la deuda, no reducirla.
• Acoplamiento entre módulos. Si tus servicios están acoplados, seguirán acoplados en Kotlin.
• Código que nadie entiende. Si un método Java de 200 líneas es incomprensible, un método Kotlin de 80 líneas con scope functions anidadas puede serlo igual.

Cambiar de lenguaje no reduce la deuda técnica. Rediseñar sí. El lenguaje es una herramienta; la deuda técnica es un problema de diseño.

He visto proyectos donde la migración a Kotlin se usó como excusa para reescribir módulos enteros. Y en algunos casos funcionó, no porque Kotlin fuera mejor que Java, sino porque la reescritura forzó un rediseño. Pero eso lo podrías haber hecho también en Java.

Mi criterio para proyectos nuevos

Si empiezo un proyecto backend hoy y tengo libertad de elección:

Lo que no aparece en los benchmarks

Los benchmarks de Java vs Kotlin miden rendimiento de compilación, rendimiento en runtime, tamaño de los binarios. Ninguno mide lo que de verdad importa a largo plazo:

• Cuántas horas tarda un nuevo miembro del equipo en ser productivo.
• Cuántos bugs llegan a producción por mal manejo de nulos.
• Cuánto tarda un code review en un proyecto mixto.
• Cuánto cuesta encontrar un candidato con experiencia en tu stack.
• Cuántas veces alguien ha roto algo porque no entendía una cadena de scope functions.

Esas métricas son las que determinan si Kotlin es la decisión correcta para tu equipo. Y dependen de tu contexto, no de las features del lenguaje.

Java no es un lenguaje obsoleto. Kotlin no es una bala de plata. La mejor decisión es la que tu equipo puede mantener durante los próximos tres años sin acumular deuda técnica invisible. A veces eso es Kotlin. A veces es Java. Y a veces es ambos, con un plan claro de convivencia.