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

Paul Sandoz paul.sandoz at oracle.com
Tue Nov 10 09:49:28 UTC 2015

> 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.

> 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.

> 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.


More information about the core-libs-dev mailing list