RFR 8020921 <was> Re: CompletableFuture updates and CompletionStage

[Doug Lea]

On 07/24/13 08:37, Paul Sandoz wrote:
>
> On Jul 24, 2013, at 12:04 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>
>> Hi Paul, Doug,
>>
>> I am happy to be considered as a reviewer for this change.
>
> Thanks!

Thanks to you both!

>
>
>> I think the separation of policies and execution mechanisms from the fluent completion-style capabilities is nice.
>>
>> Some minor comments/questions:
>> 1) Should CS.toCompletableFuture declare UnsupportedOperationException
>>    in its @throws ?
>>
>
> What is the convention for declaring runtime exceptions? I notice Iterator.remove does not declare runtime exceptions.
>

I think the convention for javadoc is to list if it provides
non-obvious information. Which might marginally hold here, so I added.

>> 2) "All CompletionStage methods are implemented independently of other
>>     public methods, so the behavior of one method is not impacted by
>>     overrides of others in subclasses."
>>
>>     I guess this could be an implNote, but then it might not be as
>>     conveniently placed.
>>
>
> That policy reads to me like a spec requirement on CF.

Yes, a meta-impl-note of sorts. Even if we were to overhaul the
internals of this class, we'd want to make sure this still
holds. This way people can confidently override for example all non-async
methods, knowing that there is no impact on async, and vice versa.


>
>
>> 3) "Actions supplied for dependent completions of non-async methods may
>>     be performed by the thread that completes the current
>>     CompletableFuture, or by any other caller of these methods. "
>>
>>     Is "these methods" referring to other SC methods, or other CF
>>     methods? It should be the latter, right.

Clarified to:

  * <li>Actions supplied for dependent completions of
  * <em>non-async</em> methods may be performed by the thread that
  * completes the current CompletableFuture, or by any other caller of
  * a completion method.</li>

Thanks also to Chris for pointing out that CompletableFuture
did not have arrangements in place for asyncs when users run with
system property java.util.concurrent.ForkJoinPool.common.parallelism
set to zero. Now it does.

-Doug