Well, here is the world as I see it: 1) all of the UI tookits I've ever heard about there is "single thread rule". In case of Swing this thread is named EDT. They could make it multithreaded, but "you should allow UI programmer to be dumb ignorant moron, he is not supposed to know about threads and synchronization". I don't mind all that stuff about EDT, but the reason of it is completely wrong to me. 2) eventually that led to concurrency bugs, which are extremely hard to reproduce. So they established simple rule - "one thread to rule them all", "thou shall not touch JComponent and it's heirs outside of EDT". If you worked with Swing starting with Java 1.4 - that rule was not established at that time, it appeared some time before java 6 release, while source code is basically the same. 3) when everybody started doing everything in EDT - it led to UI freezing (or graying out) because EDT was busy with some time consuming tasks and was not able to iterate over "dirty regions" to repaint them. So they've made SwingWorker to simplify backgrounding of time-consuming tasks. By time consuming in most cases we mean IO operations and remote invocation, which are unpredictable, while it's pretty safe to execute any code while it works only with reasonable amount of CPU time and RAM. All those methods in SwingWorker are far from lightweight, for example publish() is gathering all that data in so called AccumulativeRunnable, collecting all that data into ArrayList, and then that AccumulativeRunnable is submitted to EDT and you'll get that list in publish(). Or creation of real Thread instance in execute() method...
So as for me - it's completely correct to initialize GUICE and construct SwingWorker inside EDT, as long as your UI is not frozen by those operations. Just try to construct and show JFileChooser and see for how long it will freeze your UI before actually showing itself and I am almost sure that you will be completely happy with your solution. On Jun 25, 7:02 am, caru <[email protected]> wrote: > Thank you for the help! > > I resolved that by having MyBackgorundThreadInterface implementation > instantiated by guice inside the EDT, since it is singleton and as such it > is instantiated eagerly. Then, when I call its methods inside > MySwingWorker.doInBackground(), as you say, such methods actually run inside > the SwingWorker thread (I verified it with AOP interceptors, what a good > stuff they are), hence without interfering with the EDT. > > Still, I am not sure whether instantiating MyBackgroundThreadInterface > inside the EDT is a good idea... I guess that it is not that bad, if you > make sure its methods will never be called inside the EDT... -- You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
