Hi Kevin, i'm glad you ask, ----- Mail original -----
> De: "Kevin Bourrillion" <kev...@google.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Core Libs Dev" <core-libs-dev@openjdk.java.net> > Envoyé: Vendredi 2 Octobre 2015 18:22:00 > Objet: Re: JEP 269: Convenience Factory Methods for Collections > Tangent: > On Fri, Sep 25, 2015 at 12:20 PM, Remi Forax < fo...@univ-mlv.fr > wrote: > > > Note that without permitting nulls, Map.of(key, Optional.of(value)) will > > > > become reasonably common, and that fact you can't serialize that will > > > > become even more strange than it already is. > > > Please don't do that, if you have a mapping between a key and something > > that > > doesn't exist, the best is to not have that mapping, > > > this is the semantics of java.util.concurrent (with null instead of > > Optional) > > and this is the only sane semantics. > > > Optional should never appear in collections/maps, it makes the code that > > deal > > with this kind of beast stupidly harder to read/write for no benefit. > > If you had no need to distinguish between not-present and mapped-to-absent, > then the idea of using a Map<K, Optional<V>> is so bizarre that I'm not sure > why we would even discuss it. > We have ~1800 occurrences of Optional-valued Maps or Caches in Google. They > do this for an actual reason: a negative result is meaningfully different > from no result. This is addressed in our Optional javadoc . mapped-to-absent means that you know the keys you are waiting for, so you can store them in an external set (list, etc) and enjoy implementations like EnumMap or the couple JSObject/HiddenClass you found in most javascript engines. Using Optional for that seem inefficient. Rémi
