Thread.interrupted() spec is confusing

Martin Buchholz martinrb at google.com
Sun Feb 18 19:50:54 UTC 2018


One can understand the desire to keep the spec wording between
Thread.interrupted and Thread.isInterrupted consistent, but we can probably
improve by @linkplain-ifying "alive" and adding the word "yet".

On Sun, Feb 18, 2018 at 10:16 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 18/02/2018 10:17, Tagir Valeev wrote:
>
>> Hello!
>>
>> A Thread.interrupted() static method (not to be confused with
>> Thread.isInterrupted() instance method) spec states:
>>
>>       * <http://hg.openjdk.java.net/jdk/jdk/file/67cdc215ed70/src/ja
>> va.base/share/classes/java/lang/Thread.java#l1030>
>>      * <p>A thread interruption ignored because a thread was not alive
>> <http://hg.openjdk.java.net/jdk/jdk/file/67cdc215ed70/src/ja
>> va.base/share/classes/java/lang/Thread.java#l1031>
>>      * at the time of the interrupt will be reflected by this method
>> <http://hg.openjdk.java.net/jdk/jdk/file/67cdc215ed70/src/ja
>> va.base/share/classes/java/lang/Thread.java#l1032>
>>      * returning false.
>>
>>
>> The Thread.interrupted() always applies to the current thread. I don't
>> understand how it's possible that a current thread is not alive. To me
>> this
>> note is redundant and should be removed. Am I missing something?
>>
>> I think the wording could be improved but this about invoking
> Thread.interrupt before the thread is started. JDK-4082705 [1] has more on
> this.
>
> -Alan
>
> [1] https://bugs.openjdk.java.net/browse/JDK-4082705
>


More information about the core-libs-dev mailing list