Skip to Main Content

Java SE (Java Platform, Standard Edition)


For appeals, questions and feedback, please email

Graphics2D.drawString clears the interrupted state.

ce5bfd77-c729-4f88-a201-09338abe5003Jan 28 2017 — edited Jan 28 2017

I know some java.awt methods clear the interrupted state of the current thread under some conditions.

I usually want to create methods that respect interruptions (i.e., ones that never clear the interrupted state except when they end with InterruptedException), so such awt methods are trouble to me.

I found the following facts in my environment (Win7 with Java SE Runtime Environment (build 1.8.0_111-b14)). I'm wondering if these behaviors are something meant to be or just bugs.


               Suppose g is obtained by [ new BufferedImage(w,h,type).createGraphics() ]. Then executing [ g.drawString(str,x,y) ] by an interrupted thread cancels the interruption (without throwing InterruptedException or anything)

               if and only if (as far as I tested) str contains a character that has not been drawn previously by any other invocation of the same method (i.e. SunGraphics2D#drawString(String,int,int)). I tested it only with alphabets(a-z).

               The previous invocation does not have to be about the same Graphics2D instance or even about the same BufferedImage.


               The first invocation of this method in a java process behaves strangely under some conditions; if the invocation is by an interrupted thread, an InterruptedException is printed into System.err and

               the interrupted state of the invoking thread is cleared (though a Toolkit instance is returned successfully and nothing is thrown).

               (I'd like to talk about another strange behavior of this method here, though technically it's not related. If its first invocation is after the start of the shutdown of the process,

               an IllegalStateException is printed into System.err (by the thread named AWT-Windows) and the invocation hangs. So if a shutdownhook wants, for example, to beep or to know the screen size,

               the process may hang, depending on whether the invocation of Toolkit#getDefaultToolkit() is first or not. Why not simply throwing a RuntimeException or something in the invoking thread?

               I'm not saying the method should work even during a shutdown, but I think that such inability should be detectable and able to be dealt with.)

First, I'd like to know whether these are bugs or not.

Second, if the cancellation of interruptions are not bugs, does it mean that java developers and programmers are thinking that we should not expect so much about interruptions?

Should I give up trying to make interruptions work, even when the task to be done is clearly determined and known to the programmer?

Efforts to create methods that respect interruptions will not pay?

Locked Post
New comments cannot be posted to this locked post.
Post Details
Locked on Feb 25 2017
Added on Jan 28 2017