¿El DAO de Kotlin debería ser opcional o nulo?

Antes de Kotlin / JPA, solía escribir mi capa DAO de esta manera:

public interface UserDao extends JpaRepository<User,Long> { Optional<User> findBySsn(String ssn); } 

Y en el lado de la persona que llama, si quiero encontrar a alguien o crear un usuario por SSN, puedo escribir esto:

 val user = userDao.findBySsn(value).orElseGet { userDao.save(value) } 

Funciona bien y se ve con fluidez.

Pero como Kotlin introduce la security nula, hay otra forma idiomática (todavía en Java):

 public interface UserDao extends JpaRepository<User,Long> { Optional<User> findBySsn(String ssn); @Query("select u from User u where u.ssn = :ssn") @Nullable User findBySsnNullable(@Param("ssn") String ssn) } 

Y en el lado del cliente:

 val user = userDao.findBySsnNullable(value) .takeIf{ it -> it != null}? : userDao.save(User(value)) 

Ambas forms funcionan bien. Pero me pregunto cuál es el preferido? ¿Es bueno para Kotlin depender del layout Optional de API de Java8? ¿Cuáles son las desventajas de que un proyecto de Kotlin dependa (o intercomunique a través de) la API de Optional / Stream Java8 (ya que Kotlin tiene la suya)?

Kotlin puede comstackr a JavaScript (no lo he estudiado). Si el proyecto depende del Optional / Stream Java, ¿tendrá problemas comstackndo a JS?

—- actualizado —-

De acuerdo con Jetbrains

No, el código común solo puede depender de otras bibliotecas comunes. Kotlin no tiene soporte para traducir el bytecode de Java en JS.

    No usaría Optional si no es necesario. Solo agrega una sobrecarga innecesaria ya que trabajar con types que aceptan nulos es más legible y más idiomático en Kotlin. No hay ninguna ventaja de usar Optional en Kotlin.

    Aquí hay otra discusión sobre eso: https://discuss.kotlinlang.org/t/java-api-design-for-kotlin-consumption-optional-or-null/2455