Come convertire la conversione da Guava Facoltativo in Java Facoltativo, senza utilizzo di istruzioni if?Conversione facoltativa da Guava a Java
if (maybeSomething.isPresent()) {
return java.util.Optional.of(maybeSomething.get())
} else {
return java.util.Optional.empty()
}
Usa guava trasformazione
maybeSomething
.transform(java.util.Optional::of).or(java.util.Optional.empty());
Non vedendo alcun ovvio motivo tecnico per scegliere tra questo e l'approccio basato su null di @ Kayaman, ero curioso di sapere se uno o l'altro mostrasse un vantaggio in termini di prestazioni. Ho eseguito alcuni test rapidi sulle prestazioni e non ho riscontrato differenze significative nei tempi di esecuzione. Ulteriori analisi mostrano significativamente più (~ 2x) allocazioni di oggetti per l'approccio basato su null. Quindi, penso che questa risposta sia sicuramente la più corretta. – JakeRobb
Che ne dici di Optional javaOpt = Optional.ofNullable(guavaOpt.orNull());?
Ciò richiede la conversione a null e back, ma con opzionale di solito si vuole lavorare con nulles – MariuszS
Vero, ma dal momento che non ci sono svantaggi nella conversione in null, questo fornisce un modo più breve per ottenere lo stesso risultato finale. – Kayaman
Vedere il mio commento sulla risposta di @ MariuszS: questa opzione esegue più allocazioni di oggetti. Se hai a che fare con un volume significativo di chiamate, la risposta alternativa, anche se leggermente più lunga (mettila in un metodo di utilità e non la guardi più), ridurrà la pressione sul garbage collector. – JakeRobb
Dipende interamente da usi che attualmente fanno dei tuoi Optionals di Guava; e il primo problema risiede nelle differenze tra entrambi.
Tra gli altri:
Ciò significa che la prima cosa che devi determinare sono i tuoi diversi usi di Guava; questo condizionerà il modo in cui dovrai costruire un equivalente Java 8.
Ma data la differenza di API per entrambi, alcuni if s lungo la strada sembrano inevitabili ...
Il mio suggerimento personale sarebbe di andare solo fino in fondo e sostituire tutti gli usi attuali di Guava di con Java 8 di ; e se è necessario un "periodo di eliminazione graduale", deprecate i metodi necessari e forniteli per tutto il tempo necessario, fino a quando l'opzione facoltativa di Guava non sarà esclusa completamente.
non sono stato io a declassare, ma sembra che tu non risponda davvero alla domanda, ma piuttosto fornisca una buona panoramica dei pro, dei contro e delle differenze tra le due implementazioni 'Opzionali 'disponibili. – Henrik
Guava Release 21 ha introdotto i metodi di conversione e fromJavaUtil nella classe Optional.
Sotto il cofano sembra essere attuato in gran parte come il suggerimento di risposta di Kayaman:
public java.util.Optional<T> toJavaUtil() {
return java.util.Optional.ofNullable(orNull());
}
...
public static <T> Optional<T> fromJavaUtil(@Nullable java.util.Optional<T> javaUtilOptional) {
return (javaUtilOptional == null) ? null : fromNullable(javaUtilOptional.orElse(null));
}
Maggiori informazioni contestuali è necessario; la tua base di codice usa ampiamente Opava di Guava? Come pensi di sostituirlo con Java 8? Come si usa l'opzionale di Guava al momento? Ti aspetteresti usi di istanze esistenti, ad esempio, in Stream .findAny()? Per prima cosa è necessaria una strategia di migrazione – fge
Come faresti con un'istruzione if? Hai provato qualcosa? –
nessun problema generale con la migrazione API, basta avere un singolo caso in cui ho bisogno di tale conversione – Libre13