Wie wird die Konvertierung von Guava Optional zu Java Optional ohne Verwendung von if-Anweisungen durchgeführt?Optionale Konvertierung von Guava nach Java
if (maybeSomething.isPresent()) {
return java.util.Optional.of(maybeSomething.get())
} else {
return java.util.Optional.empty()
}
Verwenden Guave Transformation
maybeSomething
.transform(java.util.Optional::of).or(java.util.Optional.empty());
Da es keinen offensichtlichen technischen Grund gab, zwischen diesem und @ Kayamans Null-basierten Ansatz zu wählen, war ich neugierig, ob der eine oder andere einen Leistungsvorteil zeigen würde. Ich machte ein paar schnelle Leistungstests und fand keinen signifikanten Unterschied in den Ausführungszeiten. Eine weitere Analyse zeigt signifikant mehr (~ 2x) Objektzuordnungen für den nullbasierten Ansatz. Also, ich denke diese Antwort ist definitiv die richtigste. – JakeRobb
Wie wäre es mit Optional javaOpt = Optional.ofNullable(guavaOpt.orNull());?
Dies erfordert die Konvertierung in null und zurück, aber mit optional in der Regel wollen Sie mit Nulles arbeiten – MariuszS
True, aber da gibt es keinen Nachteil bei der Umwandlung in null, dies bietet einen kürzeren Weg, um genau das gleiche Endergebnis zu erhalten. – Kayaman
Siehe meinen Kommentar zu @ MariuszS Antwort - diese Option führt mehr Objektzuweisungen durch. Wenn Sie mit einer beträchtlichen Anzahl von Aufrufen zu tun haben, wird die alternative Antwort zwar etwas länger (setzen Sie sie in eine Hilfsmethode und sehen Sie sie nie wieder an), wird aber die Belastung für den Garbage Collector verringern. – JakeRobb
Es ganz auf die Verbräuche ab, die Sie zur Zeit Ihrer Guava der Optionals tun; und das erste Problem liegt in den Unterschieden zwischen beiden.
unter anderem:
Was bedeutet, das erste, was Sie feststellen müssen, ist Ihre verschiedenen Verwendungen von Guava; Dies wird die Art und Weise konditionieren, wie Sie ein äquivalentes Java 8 erstellen müssen.
Aber der Unterschied in der API für beide gegeben, scheinen einige if s auf dem Weg unvermeidbar ...
Mein hier persönlicher Vorschlag nur würde den ganzen Weg zu gehen und alle aktuellen Anwendungen von Guava ist mit Java 8er ersetzen ; und wenn ein "Ausstiegszeitraum" erforderlich ist, verwerfen Sie die erforderlichen Methoden und stellen Sie sie so lange wie nötig bereit, bis Guava's Optional vollständig ausgeschlossen ist.
Es war nicht ich, wer downvoted, aber Sie scheinen nicht wirklich die Frage zu adressieren, aber geben Sie lieber einen schönen Überblick über die Vor- und Nachteile und Unterschiede zwischen den beiden verfügbaren 'Optional'-Implementierungen. – Henrik
Guava Release 21 eingeführt die toJavaUtil und fromJavaUtil Konvertierungsmethoden in die Optional Klasse.
Unter der Haube weitgehend als Vorschlag in der Antwort von Kayaman umgesetzt wird es scheint:
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));
}
Weiteren Kontextinformationen benötigt wird; verwendet Ihre Codebasis Guava's Optional umfangreich? Wie planen Sie, es durch Java 8 zu ersetzen? Wie benutzt du derzeit Guava's Optional? Werden Sie die Verwendung vorhandener Instanzen beispielsweise in Streams .findAny() erwarten? Sie benötigen in erster Linie eine Migrationsstrategie – fge
Wie würden Sie es mit einer if-Anweisung machen? Hast du irgendwas probiert? –
kein generelles Problem mit api migration, habe nur einen Fall, wo ich solche Konvertierung brauche – Libre13