It may be useful to provide in the APIs (or at least openidex for the time
being) proxies which would avoid loading certain kinds of actions until they
were run.

E.g. for CallableSystemAction, make a class which implements Action and also
Presenter.* (using Actions.connect) and which must be initialized with the name
of a class which is a subclass of CallableSystemAction. Also provide a public
static factory method taking a FileObject which would check for the class name
as a file attribute. The display name/icon of the action should also be taken
from the data node for the file. Now in your layer you could write e.g.:

<folder name="Menu">
    <folder name="Tools">
        <file name="org-nb-modules-me-myaction.instance">
            <attr name="instanceCreate"
methodvalue="org.openidex.util.actions.CallableSystemActionProxy.create"/>
            <attr name="actionClass" stringvalue="org.nb.modules.me.MyAction"/>
            <attr name="SystemFileSystem.localizingBundle"
stringvalue="org.nb.modules.me.Bundle"/>
            <attr name="SystemFileSystem.icon"
urlvalue="nbresloc:/org/nb/modules/me/MyActionIcon.gif"/>
        </file>
    </folder>
</folder>

For CookieAction's which do not need to override enable(Node[]), i.e. for which
cookieClasses() and mode() suffice to determine their enablement, the same trick
could work though it is a little more difficult; the cookie classes and mode
would then need to be specified as file attributes as well. These are normally
tool actions; if jpokorsky makes it possible to install these other than by
manifest then this could be useful.

By using a proxy you would avoid loading the real action class until the user
actually selected the menu item or whatever. The savings in classes loaded would
include not just the action but maybe some other classes it refers to at compile
time.