Rémi Forax's Blog

SwingWorker's process signature

Preamble : this is my first blog entry, so champagne!!

Ok, you have perhaps notice it, the signature of the SwingWorker's process method change in the last beta (b92), and you can blame someone for that ... me.

I'm proud to have reported this bug (6432565) even if for patch it, the interface of SwingWorker has been changed. After all the JDK is still in beta.

SwingWorker is used to publish data from an external thread (the worker thread) to the EDT (Event Dispatch Thread), because, in Swing, only the EDT can change GUI states.

The EDT is in charge of dispatch events, refresh the gui, etc. so the worker thread can call publish several times before the process method is called by the EDT, so the published data need to be gathered. Swingworker uses a list to store these data and then calls the process method. Before b92 a new array was created from that list and pass as parameter to the process method.

So where is the bug ? The bug comes when you try to allocate this array, it's a parameterized array (by T), and in Java at runtime you can't know the declared type used for T and THERE IS NO WAY TO DETERMINE IT EVEN USING REFLECTION.

So how to correct the bug, it's easy, use instead a list of T.

PS: I don't write this blog to blame the SUN ingeneer that wrote that code. For the record, two weeks after, on another bug i try to convince him that it was possible to guess the class of a type variable at runtime using a smart trick, of course, the proposed code was wicked.

Comments

• Readers might be interested to know that Swing can be rendered from outside the EDT by installing a SynchronizedEventQueue. This synchronized sub-class of EventQueue is described in this thread: http://www.javagaming.org/forums/index.php?topic=13211.0

  Posted by: commanderkeith on July 26, 2006 at 09:15 PM

• There's one nasty problem with multithreading hacks: they can seem to work for a long time, until it becomes obvious that they don't. I strongly recommend that you read the following before you assume you've found a loophole in the single-threaded-rendering rule:

  http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html

  Posted by: isaac32767 on September 13, 2006 at 05:48 PM

• 
  the loophole was not a thread problem but a generics one,
  see the bug report.

  but thank you for the link.

  Remi Forax

  Posted by: forax on September 13, 2006 at 11:55 PM

This work is licensed under a Creative Commons License.