The actions are implemented using lazy delegate for performance reasons. The actual action is not instantiated until its invocation. For the same reason, it is difficult to compute the 'enabled' state, especially if it depends on enablement of the underlying EditorKit's delegate action.

There are actually 3 cases covered by WrapperAction: global actions such as Go To {symbol, file, class}, regardless of whether some Editor has focus. Such actions must remain enabled at all times.

2nd group of actions are actions which are specific to a MIME type; they should disable themselves if the focused Node does not lead to a DataObject of the required MIME type. Organize Imports/Members are good examples: they should perhaps remain enabled even though the Editor looses focus as long as a Java file is in the node 'scope' (Lahvaci, do you agree ? Those actions are yours)

3rd group contains actions, which depend on the focused editor's  properties, like selection and/or caret position. Move Code Element up/down are a good examples.

Sadly there is no way how to distinguish between group 1 and 3 at this moment. It would be possible to extend @EditorActionRegistration with an additinal attribute that disables the wrapper iff no editor has focus at the moment. 

Note that the above still does not fix actions, which contain its custom enablement code or logic. The actions generally use setEnabled() call on themselves to mutate their state; if isEnabled() was overriden to provide state, it could be detected from the action's class by the @EditorActionRegistratin processor and turned to a flag. Should the real action been created for 'enable' evaluation, the performance would be decreased, which is unacceptable given the number of actions in the main menu.

So the proposal is:

1/ extend the WrapperEditorAction to check for the focused node and presence of a DataObject with appropriate mime type, if the Wrapper was registered for a particular mime type.

2/ extend the @EditorActionRegistration to declare the 'enablement' policy of the action: GLOBAL (always enabled), FOCUSED (editor must be focused), 

3/ add a CUSTOM enablement policy (FOCUSED + call to the action's isEnabled handler)

Milo - agree ?

In case of CUSTOM we could trigger asynchronous delegate creation in case the menu gets constructed so that the menu appears quickly but the actions eventually get properly enabled/disabled.

This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss

Still valid in:

Product Version: NetBeans IDE Dev (Build 201607140002)
Java: 1.8.0_92; Java HotSpot(TM) 64-Bit Server VM 25.92-b14
Runtime: Java(TM) SE Runtime Environment 1.8.0_92-b14
System: Windows 7 version 6.1 running on amd64; UTF-8; en_US (nb)