¿Qué peligros existen al pasar una lambda de Java a un método en Kotlin?

Al pasar una lambda desde Java a un método en Kotlin:

1. Conversión SAM: La lambda en Java debe corresponder a una interfaz funcional (interfaz con un solo método abstracto) para que la conversión automática a un tipo funcional en Kotlin ocurra. Si la lambda no cumple con esa interfaz, no se realizará la conversión automática y será necesario un cambio manual o un envoltorio.
2. Tipo Nullable: El tipo funcional en Kotlin obtenido desde Java, por defecto, no es nullable (() -> Unit). Si el método en Kotlin espera un tipo nullable (() -> Unit)?), puede ser necesario especificar explícitamente el tipo nullable en Kotlin al llamar desde Java.
3. Excepciones: Las excepciones que pueda lanzar el código dentro de la lambda en Java no se manejan automáticamente en Kotlin. El código en Kotlin debe manejar explícitamente estas excepciones usando try-catch.
4. Rendimiento: Aunque la conversión SAM suele ser eficiente, en algunos casos la creación excesiva de objetos envoltorios para lambdas puede afectar ligeramente el rendimiento.
5. Compatibilidad de versiones: Las características de interacción entre Kotlin y Java pueden cambiar entre versiones de los compiladores, por lo que puede requerir atención al actualizar.

Ejemplo:

// Código Java
interface MyFunctionalInterface {
    void doSomething();
}

class JavaConsumer {
    public void consume(MyFunctionalInterface callback) {
        callback.doSomething();
    }
}

// Código Kotlin
class KotlinUser {
    fun useConsumer(consumer: JavaConsumer) {
        // Conversión automática de SAM de la lambda en Java a tipo funcional en Kotlin
        consumer.consume { println("Haciendo algo desde Kotlin") }

        // Ejemplo donde puede ser necesario un tipo nullable en la función Kotlin,
        // si el método Java puede aceptar null
        // fun consumeNullable(callback: (() -> Unit)?) { ... }
    }
}