Menu

#125 Optional.or() can use a covariant Supplier as parameter

1.4-stable
closed
2015-11-14
2015-11-03
No

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)

Discussion

  • Stefan Zobel

    Stefan Zobel - 2015-11-03
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -1,10 +1,10 @@
     The signature could e.g. be
    
    -public <S extends T> Optional<T> or(Supplier<Optional<S>> supplier)
    +    public <S extends T> Optional<T> or(Supplier<Optional<S>> supplier)
    
     rather than
    
    -public Optional<T> or(Supplier<Optional<T>> supplier)
    +    public Optional<T> or(Supplier<Optional<T>> supplier)
    
    
     See: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036186.html
    
     
  • Stefan Zobel

    Stefan Zobel - 2015-11-03

    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
  • Stefan Zobel

    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).

     
  • Stefan Zobel

    Stefan Zobel - 2015-11-03
    • status: open --> accepted
    • Milestone: on hold --> 1.4-stable
     
  • Stefan Zobel

    Stefan Zobel - 2015-11-04
    • summary: Optional.or() could use a covariant Supplier as parameter --> Optional.or() can use a covariant Supplier as parameter
     
  • Stefan Zobel

    Stefan Zobel - 2015-11-05

    Note that the more obvious

    public Optional<T> or(Supplier<Optional<? extends T>> supplier)
    

    leads to compilation problems. For example, the following code doesn't compile:

    Optional<CharSequence> cs = Optional.ofNullable(null);
    Supplier<Optional<StringBuilder>> ssb = new Supplier<Optional<StringBuilder>>() {
        @Override
        public Optional<StringBuilder> get() {
            return Optional.ofNullable(null);
        }
    };
    Optional<CharSequence> cs2 = cs.or(ssb);
    

    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>

     
  • Stefan Zobel

    Stefan Zobel - 2015-11-14

    Finished. All 17736 test pass on

    • 1.6.0_45-64bit
    • 1.7.0_80-64bit
    • 1.8.0_66-64bit
    • 1.9-ea_91-64bit
     
  • Stefan Zobel

    Stefan Zobel - 2015-11-14
    • status: accepted --> closed
     

Anonymous
Anonymous

Add attachments
Cancel