I've been adding such assertions (usually as soft checks that do a Thread.dumpStack with some explanation) and it has helped, but it's also caused problems. E.g., the main app our library supports is a Swing desktop app, but there's an applet too, and applets (afaict) are instantiated on a non-EDT thread. Having our soft check run then seemed to get flagged by the Java plugin as an exception, even though it only dumps a stack, not throws an exception. That made it a hard check, and I don't think we can make the check pass other than threading a value through to make the check not happen.
We're still looking into this, so there's a chance the above about applets is partially or entirely wrong. On Tue, Sep 28, 2010 at 2:07 PM, Jess Holle <je...@ptc.com> wrote: > On 9/28/2010 7:27 AM, Ricky Clarkson wrote: >> >> A language that makes it harder to build up large broken codebases is >> needed. E.g., in Swing, it's really hard to unpick an evolved large >> program that does concurrency wrong without breaking bits, whereas >> .NET throws an exception if you instantiate a component on the wrong >> thread, making that particular screwup impossible (unless you never >> test the code and just keep growing it instead). > > This is a truly silly issue with Swing. The Swing team has argued in > forums, BOFs, etc, that one should use AOP or other approaches to add > assertions to Swing that things are done on the appropriate thread. That's > a royal cop out. No one other than the Swing team truly knows precisely > which things must always be done on a particular thread -- and it therefore > *must* be their job to add appropriate assertions to this effect. I > understand Sun was in a financial bind for the last few years -- that would > have been an honest answer to the plea for such assertions in Swing. It > clearly must be done and must be done by the Swing team, though. > > -- > Jess Holle > > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
