[concurrency-interest] Future.isCompletedNormally Future.isCompletedAbnormally

Vitaly Davidovich vitalyd at gmail.com
Thu Mar 5 00:41:26 EST 2015


Personally,  I'm not seeing the "makes sense for FJT thus also for higher
level Future" reasoning, but maybe that's just me.

It's not about resetting the interrupt status (which happens as well), but
even simpler case where someone decided to throw interrupted exception on
each get ().  I guess what I don't like about this is control flow (with
possible infinite looping) based on calling into the abyss (i.e. some
random Future impl).

Moreover, as mentioned, these seem like util/helper methods and not a core
concept to the interface - I'm not sure slapping them on via default
methods is worth the clutter.

sent from my phone
On Mar 5, 2015 12:33 AM, "Martin Buchholz" <martinrb at google.com> wrote:

>
>
> On Wed, Mar 4, 2015 at 9:23 PM, Vitaly Davidovich <vitalyd at gmail.com>
> wrote:
>
>> What's the motivation for doing that? Why moving this up in the hierarchy
>> is desired? These methods seem like utilities one would write on top of
>> their own concrete implementations.
>>
>
> The motivation is "if these methods make sense for ForkJoinTask, then they
> make sense for all Futures".
>
>> Also, what's the purpose of the labeled loop? Moreover, what if get () on
>> that impl always throws interrupted exception - this loops forever? I guess
>> I don't like this because it makes assumptions about how the implementation
>> behaves in get ().
>>
>
> Let's first decide whether we want these methods before fixing esoteric
> bugs (throwing InterruptedException without clearing the interrupt status,
> really?)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20150305/b27caaaa/attachment.html>


More information about the Concurrency-interest mailing list