Java vs Kotlin en proyectos reales

Cuando alguien compara Java vs Kotlin, casi siempre se encuentra tablas de features y benchmarks sintéticos. Pero en proyectos reales lo que de verdad pesa es:

• Qué lenguaje te permite entregar más rápido.
• Cuál te da menos sustos en producción.
• Cómo afecta al equipo y al mantenimiento de la base de código.

En mi caso, vengo de muchos años trabajando con Java en proyectos de todo tipo, y desde hace varios años también mantengo y desarrollo código en Kotlin en paralelo. Eso significa convivir a diario con repos híbridos, módulos heredados en Java y nuevas funcionalidades escritas ya en Kotlin. Lo que vas a leer aquí viene de ese contraste constante.

Panorama general: por qué Java vs Kotlin no es un debate teórico

Más que elegir un ganador absoluto entre Java vs Kotlin, la pregunta práctica suele ser:

• ¿Qué mantengo en Java porque funciona y es estable?
• ¿Dónde me compensa introducir Kotlin para ganar productividad?
• ¿Cómo gestiono un código base híbrido sin volver loco al equipo?

La clave: Kotlin vive en el mismo ecosistema JVM que Java, se integra con sus librerías y frameworks, y puedes mezclar ambos lenguajes en el mismo proyecto. Eso te permite pensar en términos de estrategia y no de “reescritura total”.

Sintaxis Kotlin vs Java en el día a día

Hablar de sintaxis Kotlin vs Java no es un tema estético. Afecta a:

• Lo que tardas en escribir una feature.
• La claridad de los PRs.
• Lo sencillo que es refactorizar.

Data classes vs POJOs verbosos

Ejemplo típico de modelo simple:

Java

public class User {
    private final Long id;
    private String name;
    private String email;

    public User(Long id, String name, String email) {
        this.id = id;
        this.name = name;
        this.email = email;
    }

    public Long getId() {
        return id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }

    @Override
    public boolean equals(Object o) {
        // equals típico
    }

    @Override
    public int hashCode() {
        // hashCode típico
    }

    @Override
    public String toString() {
        return "User{id=" + id + ", name='" + name + "', email='" + email + "'}";
    }
}

Kotlin

data class User(
    val id: Long,
    var name: String,
    var email: String
)

En bases de código grandes, esta diferencia se multiplica por cientos de clases. Después de años manteniendo ambos, se nota que:

• Kotlin reduce muchísimo el código repetitivo.
• Los diffs de PR son más pequeños y fáciles de revisar.
• Refactorizar modelos es más sencillo y menos propenso a errores.

Null safety: de los NPE “sorpresa” a errores en compilación

Una de las diferencias más importantes en la sintaxis Kotlin vs Java es cómo se trata el null.

Java: NullPointerException en cualquier sitio

public String getUserEmail(User user) {
    return user.getProfile().getEmail().toLowerCase();
}

Si user, profile o email son null, el bug aparece en tiempo de ejecución. Puedes evitarlo con if anidados o Optional, pero no es obligatorio.

Kotlin: tipos anulables y operadores seguros

fun getUserEmail(user: User?): String? {
    return user
        ?.profile
        ?.email
        ?.lowercase()
}

• User? obliga a pensar si el usuario puede ser null.
• El operador ?. encadena accesos seguros.
• Si algo es opcional, el tipo lo deja claro.

Con varios años usando Kotlin junto a Java, se nota cómo se desplaza un montón de errores de runtime a compile time, algo clave en proyectos donde muchos desarrolladores tocan el mismo código.

Funciones de extensión vs utilidades estáticas

En Java es habitual terminar con clases tipo *Utils llenas de métodos estáticos.

public class PriceUtils {

    public static BigDecimal applyVat(BigDecimal basePrice, BigDecimal vatPercent) {
        if (basePrice == null || vatPercent == null) {
            return BigDecimal.ZERO;
        }
        BigDecimal multiplier = vatPercent
                .divide(BigDecimal.valueOf(100))
                .add(BigDecimal.ONE);
        return basePrice.multiply(multiplier);
    }
}

Uso:

BigDecimal finalPrice = PriceUtils.applyVat(basePrice, vatPercent);

Kotlin: funciones de extensión

fun BigDecimal.applyVat(vatPercent: BigDecimal?): BigDecimal {
    if (vatPercent == null) return this
    val multiplier = vatPercent
        .divide(BigDecimal(100))
        .plus(BigDecimal.ONE)
    return this.multiply(multiplier)
}

Uso:

val finalPrice = basePrice.applyVat(vatPercent)

Esto convierte el API interno en algo más cercano al dominio: lees el código y parece casi una frase. Tras trabajar con ambos estilos, se nota que Kotlin facilita crear mini-DSLs que hacen que la lógica de negocio se entienda mejor.

Rendimiento Kotlin vs Java en la práctica

Cuando se habla de rendimiento Kotlin vs Java, hay dos escenarios distintos:

1. Rendimiento en compilación.
2. Rendimiento en ejecución.

Compilación: builds rápidos vs features potentes

En proyectos grandes, especialmente con muchos módulos y anotaciones, lo que se ve en el día a día es:

• Java suele compilar algo más rápido de forma consistente.
• Kotlin puede penalizar cuando:
  • Hay mucho uso de data class.
  • Se usan intensivamente coroutines y genéricos.
  • Entra en juego KAPT y procesadores de anotaciones.

No es dramático, pero si vienes de builds muy rápidos en Java se nota cuando empiezas a introducir Kotlin sin cuidar la estructura.

Un enfoque que me ha funcionado:

• Módulos “core” muy estables: se pueden mantener en Java si la compilación es un cuello de botella.
• Módulos de lógica de negocio, más cambiantes: aquí Kotlin compensa por su productividad.

Rendimiento en ejecución: la JVM manda

En términos de CPU y memoria, en la mayoría de aplicaciones empresariales no se observa una diferencia significativa entre código equivalente en Java y en Kotlin:

• Ambos acaban generando bytecode JVM similar.
• El cuello de botella real suele estar en:
  • Acceso a base de datos.
  • Llamadas a otros servicios.
  • Diseño de la arquitectura.

En escenarios de rendimiento crítico, la estrategia que mejor me ha funcionado ha sido:

1. Escribir la lógica normalmente en Kotlin (por productividad).
2. Hacer profiling real en entorno de carga.
3. Optimizar solo los hotspots, incluso usando estilos más “Java clásicos” donde haga falta.

Concurrencia: threads y futures vs coroutines

Una de las diferencias prácticas más notables en Java vs Kotlin es cómo modelas trabajo asíncrono.

Java: ExecutorService y CompletableFuture

ExecutorService executor = Executors.newFixedThreadPool(10);

public CompletableFuture<OrderSummary> buildOrderSummary(Long orderId) {
    return CompletableFuture.supplyAsync(() -> loadOrder(orderId), executor)
        .thenCombineAsync(
            CompletableFuture.supplyAsync(() -> loadOrderLines(orderId), executor),
            (order, lines) -> new OrderSummary(order, lines),
            executor
        );
}

1. Poderoso, pero la composición de futures se vuelve verbosa.
2. El manejo de excepciones hay que cuidarlo mucho.

suspend fun buildOrderSummary(orderId: Long): OrderSummary = coroutineScope {
    val orderDeferred = async { loadOrder(orderId) }
    val linesDeferred = async { loadOrderLines(orderId) }

    OrderSummary(
        order = orderDeferred.await(),
        lines = linesDeferred.await()
    )
}

• El código parece casi síncrono.
• suspend y coroutineScope hacen explícito el flujo.
• Componer trabajos concurrentes es más legible.

Cuando llevas años manteniendo servicios en Java y luego introduces Kotlin con coroutines, la sensación es que pasas de “pelearte con la API de concurrencia” a “expresar la lógica de lo que realmente necesitas hacer”.

Mejores prácticas Java y Kotlin en bases de código mixtas

En proyectos reales, el escenario más común no es “100% Java” vs “100% Kotlin”, sino un código base híbrido. Ahí entran en juego las mejores prácticas Java y Kotlin.

Separar por estabilidad y dominio

Algo que ayuda mucho es organizar módulos en función de:

• Estabilidad del código:
  • Núcleo muy estable: se puede quedar en Java sin problema.
  • Capas de negocio muy cambiantes: Kotlin aporta mucha agilidad.
• Cercanía al dominio:
  • Código que modela conceptos de negocio ➝ Kotlin encaja especialmente bien (data classes, sealed classes, DSLs, etc.).

Estrategia de migración gradual

En lugar de reescribir todo, una estrategia que he aplicado en varios proyectos es:

1. Mantener el código existente en Java.
2. Escribir funcionalidad nueva en Kotlin cuando sea posible.
3. Migrar a Kotlin solo las clases Java donde el mantenimiento es doloroso:
   • Mucha lógica de negocio.
   • Muchos bugs recurrentes.
   • Refactors frecuentes.

Así se evita el shock de una reescritura total y el equipo se acostumbra a Kotlin poco a poco.

Testing en Kotlin para proyectos mayoritariamente Java

Un truco muy práctico para introducir Kotlin sin riesgo es empezar por los tests:

• Es un área donde la sintaxis concisa de Kotlin brilla:
  • Builders para datos de prueba.
  • DSLs “given/when/then”.
  • Extensiones para asserts.

Ejemplo de test en Kotlin sobre código Java

class OrderServiceTest {

    private val repository = InMemoryOrderRepository()
    private val service = OrderService(repository)

    @Test
    fun `should create order with lines`() {
        val request = orderRequest {
            customerId = 123L
            line {
                productId = 1L
                quantity = 2
            }
            line {
                productId = 2L
                quantity = 1
            }
        }

        val order = service.createOrder(request)

        assertThat(order.lines).hasSize(2)
        assertThat(order.customerId).isEqualTo(123L)
    }
}

fun orderRequest(block: OrderRequestBuilder.() -> Unit): OrderRequest =
    OrderRequestBuilder().apply(block).build()

class OrderRequestBuilder {
    var customerId: Long = 0
    private val lines = mutableListOf<OrderLineRequest>()

    fun line(block: OrderLineRequest.() -> Unit) {
        lines += OrderLineRequest().apply(block)
    }

    fun build() = OrderRequest(customerId, lines)
}

Este tipo de DSL para tests es mucho más natural en Kotlin que en Java, y sirve como puerta de entrada para que el equipo se familiarice con el lenguaje.

Casos típicos: Android, backend y librerías internas

Android: Kotlin como estándar de facto

En Android, el debate Java vs Kotlin está prácticamente decantado:

• La mayoría de ejemplos, documentación y librerías modernas ya se centran en Kotlin.
• El ecosistema de coroutines y Flow encaja muy bien con el manejo de estado y UI moderna.

Si hoy empezara una app Android desde cero, no tendría duda: la base estaría en Kotlin y Java quedaría reservado para integrar SDKs antiguos o librerías muy legacy.

Backend: Spring, Ktor y compañía

En backend el panorama es más equilibrado:

• Si tienes una plataforma enorme basada en Java y Spring de años, no hay prisa por migrar todo.
• Pero Kotlin encaja de maravilla en:
  • Servicios nuevos basados en Spring Boot.
  • Servicios ligeros con Ktor o frameworks similares.
  • Capa de dominio y DTOs.

Ejemplo de controlador REST

Java (Spring)

@RestController
@RequestMapping("/api/orders")
public class OrderController {

    private final OrderService service;

    public OrderController(OrderService service) {
        this.service = service;
    }

    @GetMapping("/{id}")
    public ResponseEntity<OrderDto> getOrder(@PathVariable Long id) {
        return service.findById(id)
            .map(order -> ResponseEntity.ok(toDto(order)))
            .orElse(ResponseEntity.notFound().build());
    }

    // mapper toDto(...)
}

Kotlin (Spring)

@RestController
@RequestMapping("/api/orders")
class OrderController(
    private val service: OrderService
) {

    @GetMapping("/{id}")
    fun getOrder(@PathVariable id: Long): ResponseEntity<OrderDto> =
        service.findById(id)
            ?.let { ResponseEntity.ok(it.toDto()) }
            ?: ResponseEntity.notFound().build()
}

fun Order.toDto() = OrderDto(
    id = id,
    customerId = customerId,
    total = total,
    lines = lines.map { it.toDto() }
)

fun OrderLine.toDto() = OrderLineDto(
    productId = productId,
    quantity = quantity,
    price = price
)

Es el mismo patrón, pero con menos carga cognitiva y un uso intensivo de extensiones.

Librerías internas y SDKs

En librerías de muy bajo nivel o SDKs internos que se consumen desde muchos proyectos Java, muchas veces compensa:

• Seguir en Java por compatibilidad y predictibilidad.
• Usar Kotlin en el código de negocio que consume esas librerías.

Checklist práctico: ¿Java, Kotlin o ambos?

A la hora de decidir entre Java vs Kotlin en un proyecto real, este checklist ayuda:

• ¿Tienes una base de código Java grande y estable?
  • Sí ➝ empieza con Kotlin en módulos nuevos y tests, no reescribas todo.
  • No ➝ Kotlin es una opción muy seria como lenguaje principal.
• ¿Cómo es el equipo?
  • Perfil muy Java clásico, poco tiempo de formación ➝ híbrido suave, introduciendo Kotlin poco a poco.
  • Perfil mixto, ganas de actualizarse ➝ apuesta más fuerte por Kotlin.
• ¿Qué pesa más ahora mismo: velocidad de entrega o estabilidad extrema?
  • Entrega rápida de nuevas features ➝ Kotlin suele ofrecer mejor productividad.
  • Estabilidad en sistemas críticos muy maduros ➝ Java sigue siendo la opción conservadora.
• ¿Qué tipo de proyecto es?
  • Android ➝ Kotlin casi por defecto.
  • Backend empresarial ➝ híbrido suele ser muy razonable.
  • Librerías internas consumidas por muchos proyectos ➝ Java puede seguir siendo la columna vertebral.

Entonces… ¿Cuál me quedo?

Después de mantener durante años proyectos en Java y otros en Kotlin, y muchos híbridos, la conclusión más honesta es que el debate Java vs Kotlin rara vez se resuelve con un “todo o nada”.

• Java sigue siendo robusto, estable, ampliamente entendido y con un tooling excelente.
• Kotlin aporta una sintaxis más expresiva, null safety, coroutines y en general una experiencia de desarrollo más agradable.

La buena noticia es que pueden convivir sin problema en el mismo proyecto. La decisión práctica pasa por:

• Usar Java donde ya tienes una base sólida y estable.
• Introducir Kotlin donde el cambio constante y la legibilidad de la lógica de negocio son clave.
• Diseñar una estrategia gradual, pensando en las personas del equipo tanto como en la tecnología.