Something I do for problematic cases is to wrap them in an EDT<T>, so instead of doing frame.setVisible(true); you do frame.get().setVisible(true); The .get() part does a thread check.
SwingWorker is good, but irritatingly swallows exceptions unless you override done() and have it call get(). I subclass it and override done, then use that subclass as my base instead of SwingWorker for future workers. On Tue, Jun 7, 2011 at 9:10 AM, Jonathan Fuerth <[email protected]> wrote: > This is an excellent idea, Fabrizio. Even once you reign in the thread > confinement errors, they start to creep back in when people go in and > refactor, "fix" bugs, add new features. It's a classic category of brittle > code. The SwingWorker helps a lot with structure and discipline, but it's > still all too easy for someone to add UI update code on the worker thread. > Your annotation will definitely help. > > Although using Lombok to insert runtime tread correctness checks is a big > step in the right direction, I'm thinking this problem cries out for static > analysis. It should be possible, no? > > I will watch this thread closely for your findings! > > -Jonathan > > On Jun 7, 2011 4:12 AM, "Fabrizio Giudici" <[email protected]> > wrote: >> In a project of mine I'm using this annotation: >> >> @Retention(RetentionPolicy.SOURCE) >> @Target({ElementType.CONSTRUCTOR, ElementType.METHOD}) >> @Inherited >> @Documented >> public @interface ThreadConfined >> { >> ThreadType type(); >> } >> >> public enum ThreadType >> { >> ANY, UI, NOT_UI >> } >> >> >> >> They are used to declare whether a method can be executed in any thread, >> only in an UI thread (technology dependent), or must *not* be invoked in >> a UI thread if the technology mandates that the UI thread must not be >> blocked. Currently they are using for documentation purposes, but sooner >> or later I'll write some Lombok extension for automatically generating >> assertions. >> >> AFAIK the Java-Concurrency annotations don't cover these semantics. >> >> I'm near to move these annotations to my general stuff library, but >> before doing I'm checking for existing stuff that does the same thing. I >> don't seem to have found much, though: >> >> + >> >> http://plugins.netbeans.org/plugin/13880/checkthread-thread-safety-analysis-using-java-annotations >> >> This is similar, but the forum is filled with porn spam, which seems to >> indicate that the project is not alive aelend kicking. >> >> >> + http://www.checkthread.org/annotation-threadconfined.html >> >> http://java.dzone.com/articles/checkthread-a-static-analysis-tool-for-java-concurrency-bugs?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+eclipsezone%2Ffrontpage+%28Eclipse+Zone%29 >> >> This is better, but it has some slightly different semantics (it >> specifies enum values for the Swing EDT and SWT UI threads, while I >> prefer to keep a generic UI). It could be worked around, though. I'm not >> sure about the @Inherited thing, which is of primary importance to me (I >> typically put annotations in MVC interfaces, which means that thread >> confinement policies are "inherited" to implementation classes). >> >> The major annoyance is that both projects aren't available in Maven >> Repos, AFAIK. I already use a handful of projects that aren't in an >> official Maven Repo, so I put them in my private repo, but I'm >> struggling to solve this issue rather than add another. >> >> Do you know something else that I should look at. >> >> Suggestions? >> Thanks. >> >> >> PS This should be also a question for the Lombok mailing list, since >> perhaps somebody is doing something similar, but given that Reiner is >> reading here I'm not cross-posting... >> >> -- >> Fabrizio Giudici - Java Architect, Project Manager >> Tidalwave s.a.s. - "We make Java work. Everywhere." >> java.net/blog/fabriziogiudici - www.tidalwave.it/people >> [email protected] >> >> -- >> You received this message because you are subscribed to the Google Groups >> "The Java Posse" 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/javaposse?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" 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/javaposse?hl=en. > -- You received this message because you are subscribed to the Google Groups "The Java Posse" 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/javaposse?hl=en.
