Cuando un desarrollador Java escucha hablar de Kotlin por primera vez, la reacción suele ser una de dos.

Primera: «Oh, interesante — debería echarle un vistazo.»

Segunda: «¿Para qué? Java funciona. El sueldo llega. Todo bien.»

Java vs Kotlin: una comparación honesta - 1

Las dos reacciones tienen sentido. Alguien pasó años aprendiendo Java, lo conoce bien, no quiere empezar de cero — eso es completamente razonable.

Pero hay una tercera reacción de la que nadie habla: «Es el lenguaje al que nuestro CTO nos migra el próximo trimestre.»

Para los tres casos — analicémoslo con honestidad. Sin declaraciones de guerra ni evangelismo entusiasta.

De dónde viene Kotlin — y qué tiene que ver Oracle

Java apareció en 1995. Treinta años — un ecosistema enorme, Spring, Hibernate, Maven, Gradle, millones de desarrolladores, montañas de documentación. Esto no muere. Vive, evoluciona y le va de maravilla.

Kotlin salió en 2016. JetBrains lo creó para sus propias necesidades — agotados por el boilerplate al desarrollar IntelliJ IDEA. La decisión clave: Kotlin compila al mismo bytecode JVM que Java. Funcionan juntos en el mismo proyecto. Sin guerra — solo herramientas diferentes.

En 2017, Google anunció Kotlin como lenguaje oficial para Android.

Oficialmente — porque los desarrolladores lo pedían y el lenguaje es más cómodo. Cierto.

Pero hay un contexto que conviene conocer.

Desde 2010, Google estaba enzarzado en una batalla legal con Oracle por el uso de las API de Java en Android. Oracle reclamaba 8.800 millones de dólares — suficiente para poner nervioso incluso a Google. El caso llegó al Tribunal Supremo de EE. UU. y solo se resolvió en 2021 con la victoria de Google. Once años de incertidumbre legal.

Kotlin de JetBrains es open source y sin riesgo de licencia. Google nunca vinculó oficialmente su decisión con el pleito. Pero como dicen — la correlación no implica causalidad, hasta que de alguna manera sí.

ALL IN ONE

El lado positivo: la competencia empujó a Oracle a desarrollar Java más activamente. Records, sealed classes, pattern matching en versiones recientes — en parte porque había que seguir el ritmo de Kotlin. Lo quisiera Oracle o no, todos los desarrolladores JVM ganaron con ello.

Sintaxis: una comparación en vivo

Una tarea — filtrar una lista de usuarios que tienen 18 años o más.

// Java
List<User> adults = users.stream()
    .filter(u -> u.getAge() >= 18)
    .collect(Collectors.toList());


// Kotlin
val adults = users.filter { it.age >= 18 }

Cuatro líneas contra una. En la mayoría de las tareas del día a día, Kotlin es notablemente más compacto.

Siendo justos: en Java todo es explícito. Lees el código y sabes exactamente qué está pasando. En Kotlin, algunas construcciones requieren adaptación. Para los principiantes, Java es en ese sentido más transparente.

Pero si llevas varios años en Java y escribes Collectors.toList() en piloto automático — a estas alturas igual ya no es «explícito», sino simplemente memoria muscular.

Null-safety: la mayor diferencia

Tony Hoare inventó null en 1965 y luego lo llamó públicamente su «error del billón de dólares». Un caso raro en que el propio autor admitió el bug. El NullPointerException le ha costado a la industria mucho más desde entonces — pero quién lleva la cuenta.

// Java
String name = null;    // El compilador no dice nada
name.length();         // NPE en runtime. Normalmente un viernes por la noche.
                       // A veces durante una demo en vivo con el cliente.

// Kotlin
var name: String = null   // Error de compilación. Inmediatamente. Antes de ejecutar.

var name: String? = null  // Explícitamente nullable — ahora sí
name?.length              // Si es null — devuelve null, no peta
name?.length ?: 0         // Si es null — devuelve 0

Java 8 introdujo Optional como solución parcial. Ayuda, pero no se usa en todas partes — y los NPE siguen pasando.

En Kotlin, la null-safety está integrada en el sistema de tipos. El compilador no dejará pasar código donde puedas pillarte un NPE sin haberlo permitido explícitamente. Como un code reviewer estricto — pero sin los comentarios de «¿comprobaste el null aquí?»

Boilerplate: data class vs POJO

Un modelo de datos sencillo — un usuario con tres campos.

// Java
public class User {
    private final String name;
    private final int age;
    private final String email;

    public User(String name, int age, String email) {
        this.name = name; this.age = age; this.email = email;
    }

    public String getName() { return name; }
    public int getAge() { return age; }
    public String getEmail() { return email; }

    @Override public boolean equals(Object o) { ... }
    @Override public int hashCode() { ... }
    @Override public String toString() { ... }
}

40-50 líneas. Podrías usar Lombok — pero eso añade una dependencia, requiere configurar el IDE, y luego alguien del equipo dice inevitablemente «a mí Lombok no me funciona».

// Kotlin
data class User(val name: String, val age: Int, val email: String)

Una línea. El compilador genera equals(), hashCode(), toString() — y también copy():

val carlos = User("Carlos", 30, "carlos@example.com")
val olderCarlos = carlos.copy(age = 31)  // Copia con un campo modificado

copy() — algo que Java no tiene de serie. Por qué — buena pregunta que Java todavía no ha respondido.

Corrutinas vs Hilos

En Java, el trabajo asíncrono pasa por Thread, ExecutorService, CompletableFuture. Potente. Pero el código se convierte rápidamente en una cadena que ni su propio autor puede descifrar un mes después.

// Java
CompletableFuture.supplyAsync(() -> fetchUser(id))
    .thenApply(user -> processUser(user))
    .thenAccept(result -> sendResult(result))
    .exceptionally(e -> { handleError(e); return null; });

// Kotlin
suspend fun loadAndProcess(id: Int) {
    val user = fetchUser(id)
    val result = processUser(user)
    sendResult(result)
}

El código Kotlin se lee como lógica síncrona normal — de arriba a abajo, sin anidamiento. Y aun así se ejecuta de forma asíncrona sin bloquear ningún hilo.

Matiz importante: las corrutinas no reemplazan a los hilos. Son ideales para cargas de trabajo I/O-intensivas — miles de operaciones ligeras sin crear miles de hilos reales del sistema. Para cómputo pesado en CPU sigues necesitando hilos. Ahí las corrutinas no ayudan.

Interoperabilidad — el argumento que a menudo se pasa por alto

Kotlin y Java funcionan juntos en el mismo proyecto. Simultáneamente.

Los ficheros Java y Kotlin conviven lado a lado. Se llaman mutuamente los métodos. Compilan al mismo JAR. Comparten las mismas bibliotecas.

Lo que significa: no es todo o nada. Puedes empezar con nuevos módulos en Kotlin sin tocar el código existente. La mayoría de los equipos hacen exactamente eso — de forma gradual, sin heroísmos, sin noches en vela.

Dónde Java gana de verdad

Documentación y Stack Overflow. Existen décadas de material sobre Java. Cualquier pregunta — ya hay cien respuestas en Stack Overflow, una de las cuales es correcta. La brecha con Kotlin se estrecha, pero sigue estando ahí.

Proyectos legacy. Un sistema construido hace 15 años sobre Java 8 que funciona — no lo toques. Sin beneficio, solo riesgo.

Entornos enterprise. En las grandes organizaciones, los stacks tecnológicos cambian lenta y dolorosamente. Java le resulta familiar a todo el mundo: al equipo, a los auditores, al departamento de seguridad. Y al nuevo desarrollador que llegará dentro de un año y preguntará «oye, ¿por qué usamos Kotlin?»

C++

Dónde Kotlin gana de verdad

Android. Caso cerrado. Google recomienda oficialmente Kotlin, todas las nuevas API están escritas para él, y Jetpack Compose es solo Kotlin. Empezar un nuevo proyecto Android en Java en 2026 provocaría en tus compañeros la misma reacción que llegar a la oficina a caballo.

Nuevos servicios backend. Menos código, null-safety integrada, corrutinas — una elección sensata para proyectos nuevos.

Kotlin Multiplatform. Lógica de negocio compartida para iOS, Android y web desde una sola base de código. Netflix, Philips y otras grandes empresas ya lo usan.

¿Realmente hay que elegir?

No.

Esto no es «Java o Kotlin». Es «solo Java, o Java más Kotlin».

Java se queda — su ecosistema es enorme y nadie reescribe código que funciona por un nuevo lenguaje. Kotlin crece — especialmente en mobile y en nuevos proyectos backend.

Conocer los dos significa más puertas abiertas. Sin perder nada de lo que ya tienes.

Para un desarrollador Java, la transición lleva semanas. Misma JVM, misma lógica. Lo único que tienes que hacer es empezar.

Si quieres meterte en Kotlin de verdad — tenemos un curso. 62 niveles, más de 1.100 ejercicios, 3 proyectos para tu portfolio. El primer nivel es gratuito.

→ codegym.cc/es/courses/kotlin

Sigue leyendo