Why is javax.swing.ActionEvent.getActionCommand() suppressed? (and a CapDesk bug)

Kevin Reid writes:
>javax.swing.ActionEvent.getActionCommand() appears to be necessary to  
>tell which of the Cancel or Open/Save buttons the user pressed in a  
>JFileChooser.
>
>Why is this method suppressed?

I don't know.  I don't see off-hand what the problem would be.

>I mentioned it to Dean Tribble and he  
>thought there might have been some sort of information-leak or  
>spoofing problem (though I don't see how the latter could happen),  
>and that this came up during the DarpaBrowser review.

There is a paragraph in the DarpaBrowser review about
javax.swing.Action, but it's talking about something different.

  We identified several risks associated with the javax.swing.Action
  interface, which encapsulates the ability to perform certain user
  interface actions (such as a cut-and-paste operation).  Many classes
  have getAction() and getActions() methods allowed, which might leak a
  surprising capability to invoke one of these actions to the malicious
  renderer.  Similarly, many classes have setAction() and setActions()
  methods allowed, which might allow a malicious renderer to change the
  action associated with a user interface event and thereby change the
  behavior of some trusted interface.  We did not have time to look at
  all code paths for all possible attacks, but we are worried about the
  risk of exposing these capabilities to a malicious renderer: thus,
  this is not a known risk, but rather is a “risk of the unknown”.  We
  suggest that these methods should be suppressed unless there is a
  convincing argument that they are safe.

  http://www.combex.com/papers/darpa-review/security-review.html

The link to the corresponding bug report doesn't work any more,
and I can't find E's current bug database to see if the bug database
entry contains any more information on this issue.