Well using event dispatch thread i modify states of global variables: e.g. keys-this can store all key strokes. Also i store mouse actions inside booleans.
That is how I store keystrokes too. The primary beef I have with doing the same thing for mouse input is that mouse input is usually handled by multiple listeners in different panels, and if I have a complex Swing component (for example a JTree or JTable) it is extremely inconvenient to force input to be handled in another Thread (or more accurately I have no idea how).
Swing is not thread save. doing stuff on the Event Dispatch Thread is not only common, sun even advises it.
Yeah, Sun advices it. I just had the impression that everyone here was doing something else, but couldn't see why. If that isn't the case then - well - that clears things up. It is quite nice to have automatic collapsing of subsequent repaint events, for example, if the game starts flickering.
Right now I use a java.awt.Canvas + BufferStrategy for painting, except from the information panels, which use passive rendering. The Canvas is convenient because the BufferStrategy does not apply to the other panels, whereas the alternative would be to equip the entire JFrame with a BufferStrategy applying to all components (since I cannot modify directly the BufferStrategy of a JComponent). This would be bad as far as I can see, because it's only a certain portion of the screen which actually has to be rendered every frame, and would result in lots of unneeded buffer activity. However it is quite hack-like to use an AWT component just in order to avoid attaching a BufferStrategy to all the other components.
One alternative is to simply rely on Swing default double buffering, but since everyone use BufferStrategy (or something even more manual) I assume this approach would be ill-fated somehow - people say it is more efficient to write your own (not that I have made any tests).