ADDITIONAL SYSTEM INFORMATION :
Windows10 (64 bit), version 1903
java 13.0.1 2019-10-15
Java(TM) SE Runtime Environment (build 13.0.1+9)
Java HotSpot(TM) 64-Bit Server VM (build 13.0.1+9, mixed mode, sharing)

A DESCRIPTION OF THE PROBLEM :
If a call of Toolkit.getDefaultToolkit() is the first one on the current java process and the caller thread is interrupted, the interruption state is cleared. I first think I should report this as RFE, not as a bug, since (0)the code as in sun.awt.windows.WToolkit seems intentionally ignoring interruption, and (1)this may be no harm to some java users except for me who want to use Thread#interrupt more seriously. (I'm interested in how people think of or deal with Thread#interrupt -- clearing both interruption flag and exception is not to be blamed? should people call interrupt repeatedly?)
I think the worst problem this bug may cause is that loops which periodically call SwingUtilities#invokeAndWait or #invokeLater (and possibly with Thread#sleep?) may not be stopped by interruption in spite of the programmer's possible intention. (Note that these two methods call getToolkit internally.) So I have decided this should be called a bug. (I actually observed the case where an interrupted thread which called SwingUtilities#invokeAndWait lost its interruption state. (but this behavior is technically not against the spec written in javadoc.)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Call Toolkit.getDefaultToolkit() by an interrupted thread. Make sure no other thread has called it before.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The thread is still in the interrupted state after the call.

---------- BEGIN SOURCE ----------
Thread.currentThread().interrupt();
Toolkit.getDefaultToolkit(); // or api methods which call it internally
System.out.println(Thread.isInterrupted());
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Call the getDefaultToolkit() in another thread before you use it.

FREQUENCY : always