Optional

[Doug Lea]

On 09/14/12 18:14, Remi Forax wrote:

> Brian and Tim, I agree with you that introducing Optional for findFirst/findAny
> is harmless,
> So if you can guarantee me that I will never have to fix perf bugs in a program
> that use Optional as return value of a hashmap or a cache, I will vote for
> Optional*.

This hits one of the basic design issues of core JDK libraries:
Core java.{lang,util} components are used vastly more than any
others. So any construction that *could* generate a time/space problem
is sure to do so, leading to lots of downstream time/cost to someday
try to address. This case seems easier than most because it can
be addressed simply by adding a couple of methods: Most people
can afford to waste an object to get nicer and less error-prone
usages. Some can't. Giving people a choice now will spare much
agony later.

A random sampling of precedents: How bad could it be to create a
new WeakRef in each call to WeakHashMap.get()? Why not
pre-allocate segments of ConcurrentHashMaps -- who
would ever create 1 million mostly empty ConcurrentHashMaps
in their program? Why not track per-reader holds with a new
mutable thread-local  counter just for the sake of throwing
more precise exceptions in ReentrantReadWriteLock? (The first
two were later addressed. The last one seems unfixable.)

-Doug