RFR 9: 8132394 : (process) ProcessBuilder support for a pipeline of processes

[Roger Riggs]

Hi Paul,

Updated Webrev to use List<ProcessHandle> instead of ProcessHandle... 
varargs.

    http://cr.openjdk.java.net/~rriggs/webrev-pipeline-8132394/

comments below...

On 11/10/2015 4:49 AM, Paul Sandoz wrote:
>> On 9 Nov 2015, at 19:55, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
>>
>> Hi Paul, Alan,
>>
>> What are the chances that varargs will be updated at some point in the future to use
>> Lists instead of arrays?  It would be a bit of thrash to try to avoid varargs if varargs
>> is likely to be updated.   It is a bit awkward at the moment though.
>>
>> I'd hope that at some point varargs caller syntax could handle automatically the case where the method
>> invoked accepts either a List<T> or T[].  Currently, providing a T[] is able to use the array as is.
>> It would make sense that it could also convert a List<T> to T[] as part of code generation.
>>
>> For the existing  Arrays.asList( pb1, pb2) or JEP 269  List.of(pb1, pb2) force the developer to
>> type extra stuff and create more objects than the current varargs usage.
>>
> Not necessarily, it depends on the literal size. Recall that varargs packs the elements into T[]. For a small number of elements a factory method can pack the elements into a List impl without an internal array. And for this case it’s all in the a wash giving the forking of processes.
I was focused more on the developer having to know and explicitly create 
a List.
The simple cases are likely to be inline and varargs is a better match 
for that.
Without the proposed  JEP 269 List convenience methods, working with 
lists is quite verbose
unless the program data model is actually dealing with lists.
But List  is a more robust encapsulation and has fewer implementation 
issues.

>
>
>> Where is varargs going?
>>
> Nowhere :-) I doubt varargs is going to be replaced, and the convenience collection factories will use it too. There would likely be circular dependencies and backwards compatibility issues and we would need to work out some sort of bridge mechanism. What we need for better varargs support is frozen arrays, and superior auto-unboxing/eliding optimizations if things inline.
>
> I like varargs! it’s very convenient, it’s great for small literal expressions, but one can quickly rub up against it. List is more easily composable than varargs.
>
> I have run up against it many times with:
>
>    public static CompletableFuture<Void> allOf(CompletableFuture<?>... cfs) {
>    public static CompletableFuture<Object> anyOf(CompletableFuture<?>... cfs) {
>
> Accepting a Collection<?> would have overall been more convenient to me. In fact i should propose such additions to CF :-)
>
> Having both varargs and List would be acceptable (as is the case for MethodType). But if there is to be only one i would choose List.
I'm not sure pipelines will be used enough to warrant extra convenience 
methods, not to mention
twice as many tests.  So the more general List<ProcessBuilder> is better 
to start with.

Thanks, Roger

[old webrev] http://cr.openjdk.java.net/~rriggs/webrev-pipeline-8132394-v1

>
>
>> And, will List<T> toArray() ever be able to properly create T[]?
>>
> That may be possible, there is an issue tracking this, it keeps getting bumped down in the the priority list of things to do.
:(

>
> Paul.