P2 because it is a regression that can cause
exceptions to be thrown by module code which
worked before.

I think rev. 1.60 of Actions.java caused a problem:

---%<---
revision 1.60
date: 2002/05/14 10:15:53;  author: pnejedly; 
state: Exp;  lines: +20 -11
Fix for #21197. Not optimal because it assumes the
multi-action will perform the first subaction on
accelerator stroke.
---%<---
[...other stuff then:]
+        boolean useAccel() {
+            return subModel.getCount() <= 1;
+        }
---%<---

The following stack trace seems to be triggered by it:

---%<---
java.lang.NullPointerException
 at
wfedit.actions.WFLocalAction$ActSubMenuModel.getCount(WFLocalAction.java:106
)
 at
org.openide.awt.Actions$SubMenu.useAccel(Actions.java:1021)
 at
org.openide.awt.Actions.updateKey(Actions.java:744)
 at
org.openide.awt.Actions$MenuBridge.updateState(Actions.java:512)
 at
org.openide.awt.Actions$SubMenu.<init>(Actions.java:949)
 at
wfedit.actions.WFLocalAction$SpecialSubMenu.<init>(WFLocalAction.java:83)
 at
wfedit.actions.WFLocalAction.getMenuPresenter(WFLocalAction.java:58)
 at
org.openide.awt.MenuBar$LazyMenu$MenuFolder.createInstance(MenuBar.java:403)
---%<---

from a submenu action created according to the
standard template, i.e.:

---%<---
// ...
private static final class SpecialSubMenu extends
Actions.SubMenu {
    // ...
    public void addNotify() {
        model.addNotify();
        super.addNotify();
    }
}
private static final class ActSubMenuModel implements
Actions.SubMenuModel {
    private List displayNames; // List<String>
    private List associatedInfo; // List<Object>
    public int getCount() {
        return displayNames.size();
    }
    // ...
}
---%<---

I have this seen same problem as well.

The regression appears to be this: that useAccel()
should not be called until addNotify() has been
called on the submenu. Otherwise it is too early
to know whether it should use an accelerator or
not, since that depends on information from the
model, which should not be computed until the menu
is really displayed.

Workaround: replace

    public int getCount() {
        return displayNames.size();
    }

with

    public int getCount() {
        return displayNames != null ?
displayNames.size() : 0;
    }

I could update the apisupport template to use this
workaround, but it would be nicer to just get the
bug fixed so there is no regression.