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.
