Updated SotL/L documents for Iteration 2

[Brian Goetz]

> I have two queries on the parallel aspects of this:
>
> 1. There's no mention (as yet) of any hooks into the underlying parallel
> implementations i.e controlling what FJPool to use. Is the thinking that
> we will go with the "default" FJPool concept as currently outlined in
> ForkJoinUtils?

Yes.  The current plan is to dump these into the default FJP.  To the 
extent we want to support an alternate pool, decomposition hints, 
resource limits, etc, we can overload parallel() to take arguments about 
where/how parallel computations are done.  Our strawman hypothesis is 
YAGNI, so we're putting that out and seeing if our hypothesis is right.

> 2. It seems to me that if arrays can be converted to stream() and
> parallel() then we no longer need the old-style
> ForkJoinUtils.parallelSort API? (Though I'm unsure where all the
> implementation code would live if we don't have it.)

They're different.  The Arrays.sort operations are explicitly in-place 
operations; stream operations will often (though not always) have more 
overhead.

Our approach for in-place updates is to add a small number of methods to 
Collection (e.g., removeIf(Predicate)) and Arrays.