class FileOpen extends ActionListener {

    public void actionPerformed(ActionEvent evt) {
    // code for the File->Open menu here
    }

} // end FileOpen()

JMenuItem menuItem = new JMenuItem("Open");
menuItem.addActionListener(new FileOpen());

Command's idea is to encapsulate the request as an object, i.e. the request: ActionListener, and the object: new FileOpen(). Tommorow I could pass a different object that implements the ActionListener interface, and the JMenuItem could care less. I think java.lang.Runnable is probably the most intuitive example of the Command design pattern.

The whole point about Command is that different objects that implement the same interface can serve as the request object, without affecting the requestor.

I do agree with most of the other patterns you've catalogued, viz.

1. Strategy - java.awt.LayoutManager, java.awt.image.ColorModel (very good examples)
2. Observer/Observable - the 1.1 DelegationEvent model, ImageObserver, though RMI's Remote interface is probably an equally good example
3. Singleton - A good example is the java.awt.Toolkit (Toolkit.getDefaultToolkit() ensuring a single instance) or the Math class (private cons, one of the "requirements" for a Singleton).
4. Abstract Factory - Toolkit (Sure. Also the SocketImplFactory, URLStreamHandlerFactory ... many others ... best example's probably the multiple look-and-feel classes in Swing)
5. Command - adding Listener objects to an Observable, as I pointed out above
6. Decorator - the whole java.io.Reader/Writer set of classes, that add functionality without subclassing, but end up creating a number of small objects in the process ... in fact, this is a "classic" example and it fits GOF's definition of Decorator to a T
7. Proxy - the RMI stubs and skeletons model.
8. Flyweight - Isn't that how javax.swing.text.Elements are stored in javax.swing.text.Document?