Hi Paul, is it a good idea to add the "{@inheritDoc}" to the toString() Javadoc of Optional (and to retain it in OptionalDouble/Int/Long)?
As Stuart Marks has observed in the Double/Int/LongSummaryStatistics case the inherited Object.toString() doc is "mostly irrelevant" (see http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/034282.html) So the {@inheritDoc} got removed from Double/Int/LongSummaryStatistics in JDK-8080450. I feel this would also be better for Optional. Stefan 2015-09-25 12:58 GMT+02:00 Paul Sandoz <paul.san...@oracle.com>: > Hi, > > Please review this change to add a method Optional.or that allows one to > better compose optionals: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080418-optional-or/webrev/ > > I also took the opportunity to clear up the JavaDoc, it was a little > inconsistent and i personally found it harder to read in source code. > > — > > Separately while we are on the topic of Optional i would be interested in > opinions on the following changes: > > > http://cr.openjdk.java.net/~psandoz/jdk9/optional-prims-filter-map/webrev/ > > 1) add methods that were missing on the primitive specializations; and > > 2) add to all variants a mapOrElseGet (otherwise known as a “fold”), which > is the equivalent of map(mapper).orElseGet(supplier). That is arguably less > mind-bending to use when transforming from Optional<T> to Optional<U>. > > Paul. >