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
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.:
<attr name="actionClass" stringvalue="org.nb.modules.me.MyAction"/>
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
Target milestone -> 3.3.1.
Reassigned to Dafe
How important, Jesse can you estimate how much it can help? If it is
really P4, I would delay it for 4.0.
I think it is a basic part of the Actions API rework planned for 3.4,
right? Since we are planning to overhaul actions, the new Commands API
should do this. No one will care about SystemAction which would be
only for compatibility.
Set target milestone to TBD
Yes, should be done to 4.0.
Adjusting priority a bit (performance), passing to Peter.
Assigned to new owner.
Surely if we want to improve action infrastructure this should be supported.
As already stated we can reduce number of loaded classes. This can have positive
impact on our startup (including warmup).
I am not sure how far we can go but probably we need to access module JARs
anyway to get the icon and name. Avoiding to open these JARs can get us even
bigger win but we do not have an estimation how many modules are opened because
they only contribute actions.
Proxies to avoid class loading are fine. I do not think it is wise to hack the
APIs to avoid opening JARs at all. We will probably never win, and anyway it
would be far better to do some local optimizations in the module class loaders
(e.g. caching previously loaded resources) than to try this.
*** This issue has been marked as a duplicate of 17597 ***