1

I'm surprised that I couldn't find a quick solution for this. I've been coding Java Swing application for a very long time. Myself, I've always coded things up nicely, so that the code only ever interacts with the various visual elements from inside the AWT thread, all nicely event driven. When outside events happens, like say, incoming data that needs displaying, I would lock a data structure, and then have the visual code repaint it, on the AWT threat. No problem there. But the problem is that there are other coders on the project, and some people have contributed code that is difficult to check up on. There are now bugs that I suspect are caused by code making changes to Swing outside the AWT thread, on another thread.

What I am after, is some sort of simple mechanism, that traps and blocks, and/or show stacktraces of offending code, that incorrectly interact with Swing on the wrong thread. Unfortunately, the javax.swing code doesn't have any checks built in. I'm thinking, make the environment headless somehow, trap some sort of low level thing, that only puts things back during a dispatched AWT event. Or, doing something very drastic, like using a custom classloader, that somehow swap out entire packages. Perhaps it's possible for different threads to have their own classloader? If that is possible, then the AWT thread might be set to see the normal javax.swing stuff, and other threads a rigged fake javax.swing.

Or, perhaps some IDEs have built in tricks to do this? I'm using IntelliJ IDEA.

Does anyone know of any tricks? It's only need during development. So overriding javax.swing using a bootclassloader is ok. I can't be the first one looking for this?

Mike
  • 2,393
  • 3
  • 25
  • 37
  • 2
    I think this question might be the same...: http://stackoverflow.com/questions/3153574/how-to-detect-swing-thread-policy-violations -- at least it might have some good answers. – Bill K Dec 05 '16 at 17:06
  • That's great! However, that traps it at the painting stage. It offers partial solutions, but possibly more than good enough. Trapping it at the repainting stage. I suppose when a component is told to do something and wishes to invoke a repaint, it would be trapped then. The only thing I could offer now is report back if this worked for me, but other than that, my question becomes a duplicate on Stackoverflow... – Mike Dec 05 '16 at 17:34
  • That's why I didn't put it as an answer or mark it as a dupe :) There were some other suggestions on that thread but I ended up down a rabbit hole when I tried to chase them (You might try an AOP approach). Another possibility--rebuild openJDK with checks in all the swing calls. Seems daunting but it's probably only a days work (and maybe a day or two to get OpenJDK to build on your machine!) to add checks into all the relevant swing method calls. – Bill K Dec 05 '16 at 17:38
  • Possible duplicate of [*How to generate exceptions from RepaintManager*](http://stackoverflow.com/q/7787998/230513), which also cites an AOP approach. – trashgod Dec 05 '16 at 20:47
  • I wonder what could be achieved using classloaders. I'm a little rusty on classloaders, but isn't it possible for a thread to have a different classloader than other threads? Perhaps it is possible to have a default classloader for all the threads that has javax.swing stripped out of it, where those packages just won't resolve. And then have the AWT thread being the one where it does resolve. I can also think of a way to solve this in development, where you have two modules, one being the visual one, that is the only one allowed to access javax.swing or else you get compile errors... – Mike Dec 06 '16 at 17:27

0 Answers0