This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 13540 - Suggest proxies for system actions to delay loading
Summary: Suggest proxies for system actions to delay loading
Status: RESOLVED DUPLICATE of bug 17597
Alias: None
Product: platform
Classification: Unclassified
Component: Actions (show other bugs)
Version: 3.x
Hardware: PC Linux
: P2 blocker (vote)
Assignee: Jiri Rechtacek
Depends on:
Blocks: 17527 17597
  Show dependency tree
Reported: 2001-07-11 19:45 UTC by Jesse Glick
Modified: 2009-08-04 16:08 UTC (History)
2 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2001-07-11 19:45:06 UTC
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"
            <attr name="actionClass" stringvalue=""/>
            <attr name="SystemFileSystem.localizingBundle"
            <attr name="SystemFileSystem.icon"

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
Comment 1 Jan Chalupa 2001-11-27 13:04:03 UTC
Target milestone -> 3.3.1.
Comment 2 rmatous 2002-02-07 10:18:48 UTC
Reassigned to Dafe 
Comment 3 David Simonek 2002-02-07 15:26:29 UTC
How important, Jesse can you estimate how much it can help? If it is
really P4, I would delay it for 4.0.
Comment 4 Jesse Glick 2002-02-07 16:18:49 UTC
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.
Comment 5 Marek Grummich 2002-07-22 11:20:30 UTC
Set target milestone to TBD
Comment 6 Marek Grummich 2002-07-22 11:22:46 UTC
Set target milestone to TBD
Comment 7 David Simonek 2002-07-26 14:09:25 UTC
Yes, should be done to 4.0.
Comment 8 David Simonek 2002-12-06 14:43:09 UTC
Adjusting priority a bit (performance), passing to Peter.
Comment 9 Jiri Rechtacek 2004-04-23 10:49:40 UTC
Assigned to new owner.
Comment 10 _ rkubacki 2005-09-15 15:08:50 UTC
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.
Comment 11 Jesse Glick 2005-09-15 18:40:10 UTC
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.
Comment 12 Jesse Glick 2009-08-04 16:08:50 UTC
Already implemented.

*** This issue has been marked as a duplicate of 17597 ***