Optional.or() can use a covariant Supplier as parameter
Backport of Java 8/9 java.util.stream API to Java 6/7 and Android
Brought to you by:
stefan-zobel
The signature could e.g. be
public <S extends T> Optional<T> or(Supplier<Optional<S>> supplier)
rather than
public Optional<T> or(Supplier<Optional<T>> supplier)
See: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036186.html
Related: https://bugs.openjdk.java.net/browse/JDK-8132097
(Stream.generate should use a covariant Supplier as parameter)
Anonymous
Diff:
Given that I've already done the same kind of "tuning" for Stream generate() / iterate() in 1.3.1 (JDK-8132097, Ticket#79) I could / should probably do that for Optional.or() also ?? What if it'll never appear in Java 9?
For one thing: the change would be backwards compatible to 1.3.2 (Optional is final) and would allow more general client code that is still "sound" type-wise in the sense that Scala's Option[+A] or the proposed Stream generate() covariant Supplier are "sound".
The other thing: If that won't get included in Java 9 you could write code against streamsupport that wouldn't compile on Java 9 (at least, it would require a (safe) cast in the Java 9 client code).
So, which option is better?
Last edit: Stefan Zobel 2015-11-03
At the moment, I'm leaning towards the "let's do it" option. A lot of the streamsupport users might never see Java 9 (think Android) and for the others some code adaptations would be required anyway (and this is not a big one - ugly though).
Note that the more obvious
leads to compilation problems. For example, the following code doesn't compile:
incompatible types: java8.util.function.Supplier<java8.util.optional\<java.lang.stringbuilder>> cannot be converted to java8.util.function.Supplier<java8.util.Optional<? extends java.lang.CharSequence>></java8.util.optional\<java.lang.stringbuilder>
Finished. All 17736 test pass on