@KevinWorkman and @PrinceC. While I appreciate both of your input on the forum since your posts are often very insightful and entertaining, in this case it's disappointing to see you repeatedly dismiss me as 'not really understanding how threading works' while failing to answer my question, which is: show me how you can make Swing render in your own thread without the event dispatch thread (EDT).
Dude, your whole response there continues to show me that you do not understand the problem you are trying to solve at all, and you really need to do some research (written by lots of other people) rather than insist we sit here and type lengthy multi-page treatises about it all.
But as a shortcut:
What you want to do with Swing is called Active Rendering. The nub of the gist is that you need to:
a) Paint in your main loop thread
b) Take any and all input events from the EDT and pass them in a thread safe manner to your main loop
or you could potentially just hop aboard the EDT and start running your game loop from there but I suspect trouble lies that way.
Useful link http://docs.oracle.com/javase/tutorial/extra/fullscreen/rendering.html
Your main issue is that Swing is designed as a passive event-loop driven system and it looks like you want to make a game which is almost always done in a totally different way. Games generally repaint the screen at a fixed rate or as fast as they can and do everything - direct input, logic, rendering - in a single thread "main loop", occasionally doing clever stuff with other threads but that tends to be somewhat advanced. They've hacked a bit at Swing to make it possible but it's not a smooth ride. If you want my advice, just stay away from Swing if you're writing a realtime game of any sort.
All this stuff about blocking, multiple EDTs, event queues, OS hooks, etc - all red herrings, none of you need it or even need to know about it which is why it's so well buried. Move along, nothing to see.