I think it's quite nice as is, my suggestions would be the following and they're a matter of personal preference as opposed to anything else:

• Change the look and feel to Nimbus
  
• Remove all the textfields and their labels, leaving only the icons, the reset button, and the scoring fields
  
• Change the scoring fields to Wins: # and Losses: # as opposed to throwing in the word time(s) and using the word Lost
  
• Put the icons in an equilateral triangle layout as opposed to side by side, maybe even throw in some arrows between them to show which beats which
  
• When the user presses one of the three playable icons, change the borders to denote the selection, for instance: blue for player, red for computer, purple if they select the same, and of course disable the buttons until Reset is pressed
  
• Reset should clear the borders, enable buttons, and reset the computer's choice

It's a custom look and feel. However, the same behavior is displayed by the standard Metal L&F (actually went ahead and tested that just to be certain), so it's not an issue that pertains specifically to the look and feel in use in the video.

What I'm creating is basically a graphical launcher for use with my Linux setup. I'm currently running DWM and it has no "graphical root menu." Learning Xlib and C programming to achieve the same results is not really my cup of tea, and there didn't seem to be anything along the lines of what I wanted out there already. Other window managers certainly, but most of the lightweights don't focus Java applications properly (and I use a few), and the remainder are typically heavyweights that simply don't play well with my system's resources.

Fortunately, now I've got it working just like I originally wanted. It starts up when the x-server is launched, a key binding brings it in to view, its "skinnable", it hides itself, the menus (along with their respective bash commands) are configurable via an XML document, and lastly no JNI used. While my original intent was to have it ever-present, through repetitive debugging, I found that I prefer it to hide. I was already used to that behavior from SithWM and JWM, not sure why I thought of changing it. You can see a simplified screenshot of the setup on my blog if you're curious farrell2k.

After an extremely obscure search on the web I happened upon the following:

javax.swing.MenuSelectionManager.defaultManager().clearSelectedPath();

By inserting that into the windowDeactivated method, it resolves the issue. Talk about tucked away in the API.

Sorry farrell2k, I realize the description leaves something to be desired. So I uploaded a video that highlights the precise moment it occurs:
Video of Problem
First things first, ignore the robed wizard, that's just a wallpaper.
Secondly, what you're viewing is the lower left corner of my laptop screen (reduced to conserve memory while recording).

Sequentially the video is as follows:

• I am in my second workspace, that's the first black screen you see where I launch my recorder from the command line (command not viewable).
  
• I switch to my first workspace, thus the robed wizard.
  
• I call up BigMenu (it was already running, it unhides).
  
• I navigate through the menus to the Pinta image editing program and select it, thereby launching it in a separate process. As you can see, BigMenu disappears, and that's supposed to happen that way.
  
• Before Pinta loads on my screen, I immediately call up BigMenu again and navigate through a couple of menus and wait.
  
• Pinta displays on the screen, thusly getting the focus, and taking it away from BigMenu, which causes BigMenu to disappear, as expected.
  
• When I call up BigMenu again, as is noticable, all menus are fully exposed (this is not ideal).
  
• Video ends with me forcibly collapsing the menus by pressing the Escape key and ending BigMenu, closing Pinta, and finally ceasing the recording.

I thought this was interesting and/or related:

PengPod