Into

[Doug Lea]

I'm happy to see "into" go. But I'm not all the way sold on whether
the best way is via more abstraction (Reducers, Tabulators, etc)
versus less. Here's the "less" version.
I don't want to argue too hard for taking this approach,
but figure that is worth describing:

For mutative additions to collections/maps, why not
just let people use either forEach(...add...)  or
parallel-forEach(...add..), depending on
whether the destination is concurrent and the source
amenable to parallelism, and/or whether, in the case of
Maps, they want put vs putIfAbsent vs merge. The idioms
are easy, and clearly reflect mutative intent. (*)

For more functional/fluent/streamy usages, you'd like
to enforce that any into-ish method creates a fresh instance
and that construction cannot interfere with anything else.
So why not treat these as factories in existing catgories:
   toCollection(), toList(), toRandomAccessList()
   toSet(), toNavigableSet();
plus grouping versions
   toMap(keyfn, ...), toNavigableMap(keyFn, ...);
(with merge- and multi- variants.)

Here the streams implementation gets to pick the
underlying concrete class. This may entail sensing
parallelism but only in the case of toList is
constrained by orderedness.
The streams implementation could pick the best applicable
options and improve them or pick others over time.
(For example, initially,, all of toCollection(), toList(),
and toRandomAccessList() could pick ArrayList.)
The implementation can also take advantage of the fact
that some collections (especially ArrayList) support fast
parallel insertion upon creation but not once published.

People who don't like the choices of concrete classes
can instead use the first option of creating some concrete
collections and  populating them.

Summary: Replace into with:
   * manual forEach-based idioms for mutative stuff
   * opaque factory-based methods for fluent/function stuff
And triage out for now any other non-collections-based into targets

(*) footnote: There are now a few more options for
parallel insertions into concurrent collections.
A while ago I added a "newKeySet" factory
method to JDK8/V8 version of CHM, so
there is now a JDK Concurrent Set implementation
that people can use. Someday similarly for skip lists,
so there will be a concurrent sorted/navigable set.
High-performance concurrent Lists are unlikely any
time soon, although ReadMostlyVector is better
than nothing. (I'm still not sure if it should move
from jsr166e.extra into JDK...).

-Doug