Why is Thread.interrupted() not possible to call with Thread.currentThread().interrupted?

I decided to revise some old multi-threading concepts. I came across interrupt methods. I read about difference between methods isInterrupted() and interrupted(). Point is interrupted() resets the flag, isInterrupted() doesn't.

I started coding and I noticed following. Method interrupted() must be used with 'prefix' of Thread, while method isInterrupted() must be used with 'prefix' of Thread.currentThread(). I wonder why. To demonstrate:

Thread.interrupted(); //compiles
Thread.currentThread().interrupted(); //doesn't compile

Thread.currentThread().isInterrupted(); //compiles
Thread.isInterrupted(); //doesn't compile

To sum, can someone tell me why do they have different calls? And what is difference between Thread. and Thread.currentThread()? I mean when I call Thread. it should directly 'focus' everything to that thread object, so I see no point of using Thread.currentThread() anywhere in Java. Can someone please clear my confusion?

interrupted() is a static method.

For static methods, the usual way to invoke them is like so:

TypeTheMethodIsIn.staticMethod();

contrast this to non-static methods which can only be invoked like so:

(expression of a type of the object containing the method).instanceMethod();

Technically, you CAN invoke static methods in this second fashion, but this is entirely pointless (no runtime lookup is done of the type), and all linter tools, including javac itself, will tell you to knock it off. Which you should heed.

Thread's interrupted() method is static. Thread's isInterrupted() method is not.

The point should be clear enough: Checking the interrupted flag is something you can do to any thread you like. However, clearing it? You can only do that to your own thread.

At some point we're delving into the feelings and thoughts of the programmer of the API on the day they programmed it, to which neither I nor anyone else on SO can give you a reasonable answer. But we can delve into why they MIGHT have done it this way.

Given that you are not supposed to modify the interrupted flag of other threads, only of your own, it COULD have been something like: Thread.currentThread().clearInterruptedFlag(), but now currentThread() is entirely superfluous; attempt to invoke it on any other thread and you'd then have to throw an exception, in order to ensure that a thread can only clear its own flag.

An alternative would be that any thread can clear any other thread's flag, or its own flag, but that is entirely nonsensical. The point of raising that flag is for the code in that thread to eventually stumble across it and exit or otherwise stop some blocking process ASAP.

So why is there no method to easily check your own flag without clearing it?

Again, API design. What point is there to this?

This is how you're supposed to use the interrupt flag:

1. If the central blocking nature of your thread is based on some sort of CPU freeze operation (defined as: Anything in the core libs that is specced to throw InterruptedException, such as obj.wait, Thread.sleep, yield, etc), you mostly don't have to do anything. If the interrupt flag is raised on your CPU feel free to entirely ignore this; soon (very soon) your thread will execute one of those 'make the CPU freeze' methods, such as Thread.sleep, and the implementations of all these methods first check the flag and will immediately throw InterruptedException without ever even freezing the CPU if they notice that it is raised (and they lower that flag immediately, as well. Either the flag is up, or InterruptedEx is thrown, never both). Which should end your method. (If you are catching InterruptedException and ignoring it, don't do that).

2. If the nature of your thread is such that it blocks but isn't specced, that it's up to the architecture. For example, if you're waiting on reading data from a network socket, who knows what is going to happen. Either the flag is ignored and there's nothing you can do about it, or, the read() call or whatever you're doing will throw IOException. It can't throw InterruptedException - the method isn't specced to allow that. The flag will NOT be up.

3. If the nature of your thread is such that the time is spent in active operation, for example, you're mining bitcoin and all you're doing is endlessly spinning that CPU, hashing algorithms together, then out of the box interrupting such a thread does nothing whatsoever. However, such a thread is highly likely to have a while loop of some sort. All you need to do is check the interrupt flag. If it is up, exit. It's up to you how: Either throw something, or, just.. exit. End your @Override public void run() {}'s code cleanly. Hey, you raised that interrupt, you get to decide what it means.

key point for #3 is that in both cases that flag should be lowered, because if it remains raised and your code falls back not to 'this thread is now over' but 'I relinquish control back to my caller', it would be highly surprising if that flag is up.

So, you end up writing code like this:

Runnable r = () -> {
    while (!Thread.interrupted()) {
        mineNextHash();
    }
};

which is short, clean, and to the point. easy peasy.