Sollte Kotlins DAO optional oder null zurückgeben?

Question

Vor Kotlin/JPA, benutzte ich meine DAO Schicht so schreiben:

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

Und in der Anruferseite, wenn ich jemanden finden wollen oder erstellen Benutzer von SSN, ich kann schreiben:

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

Es funktioniert gut und sieht fließend.

Aber da Kotlin stellt null-Sicherheit gibt es eine weitere idiomatische Weg ist (dao noch in 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) 
} 

Und in der Client-Seite:

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

Beide Wege gut arbeiten. Aber ich frage mich, welches ist bevorzugt? Ist es für Kotlin gut, abhängig von Java8 Optional in API-Design? Welche Nachteile hat ein Kotlin-Projekt, wenn es sich auf Java8s Optional/Stream API stützt (oder mit ihr kommuniziert) (da Kotlin seine eigene hat)?

Kotlin kann auf JavaScript kompilieren (ich habe das nicht untersucht). Wenn das Projekt von Javas Optional/Stream abhängt, wird es Probleme beim Kompilieren von JS geben?

---- ---- aktualisiert

Nach Jetbrains

Nein, gemeinsamer Code nur auf anderen gemeinsamen Bibliotheken abhängen. Kotlin hat keine Unterstützung für die Übersetzung von Java-Bytecode in JS.

Answer 1

Ich würde Optional nicht verwenden, wenn Sie nicht müssen. Es fügt nur unnötigen Overhead hinzu, da das Arbeiten mit Nullable-Typen in Kotlin lesbarer und idiomatischer ist. Es gibt keinen Vorteil der Verwendung von Optional in Kotlin.

Hier ist eine andere Diskussion dazu: https://discuss.kotlinlang.org/t/java-api-design-for-kotlin-consumption-optional-or-null/2455