Node refactoring

[Paul Sandoz]

Hi

This webrev continues the node refactoring:

  http://cr.openjdk.java.net/~psandoz/lambda/node/node/webrev/lambda-jdk.patch

- Node is called out for what it really is, a Node in a tree, thus may have children. It can be flattened which may result in using F/J to flatten the leaf nodes into an array.

- Method to create a Node from a collection or streamable or stream. The latter will result in collection of the stream.

- NodeBuilder supports in place update, as required by CumulateOp.

- ToArrayOp.evaluateParallel can now determine if it will be converting a stream accessor holding a node to an array, and can therefore optimise, by flattening the node and obtaining the array, which may in some cases (e.g. if after sort) be the propagation of the array reference of the sorted elements.


Further modifications to be considered:

- I am inclined to remove the use of NodeBuilder in GroupByOp and replace with ArrayList. Thus NodeBuilder does not need to extend from or be viewed as a Collection.

- The pipeline helper can create a NodeBuilder that is optimised based on the flags and size information plus can also collect to produce a Node:

      NodeBuilder<P_OUT> makeBuilder();
      Node<P_OUT> collect();
      NodeBuilder<P_OUT> makeBuilderFor(Spliterator<P_IN> sp);
      Node<P_OUT> collectFrom(Spliterator<P_IN> sp)

TreeUtils.collect can be encapsulated into the pipeline helper impls and thus hiding a lot of details around constructing and building nodes.

- CollectorOp can be a first class op that defers to the helper.      

- Node.flatten could be removed and instead this could be on pipeline helper if we need to unify F/J invocation in the helper. I am not sure that is important though.


--

Basically more and more stuff is getting encapsulated into the pipeline helper, which seems a good thing.

Paul.