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 36454 - Lazily compute exact list of new/paste types
Summary: Lazily compute exact list of new/paste types
Alias: None
Product: platform
Classification: Unclassified
Component: Nodes (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: Jaroslav Tulach
Depends on: 35827
  Show dependency tree
Reported: 2003-10-06 18:10 UTC by Jesse Glick
Modified: 2010-04-06 18:24 UTC (History)
3 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 2003-10-06 18:10:18 UTC
There is a bit of a performance problem in the
context menu for Ant scripts (mainly the DataNode,
though perhaps also subnodes). If you invoke the
context menu for the first time in a session
intending to e.g. select one of Run Targets...,
the module loads the Ant type/task introspection
info. The only reason it does this (AFAIK) is to
create the list of NewType's to be displayed in
the New... submenu - containing e.g. <target> and
types, which are permitted at top level. NewAction
requests the NewType's to determine if it should
display the menu item as disabled, enabled as a
single item, or enabled as a submenu - note that
it is not using the actual NewType's until you
post the submenu, however.

One workaround in the Ant module is to have in
New... only fixed types such as <target> and
"Type...". But this might be annoying as it forces
the user to then select the type from a dialog,
rather than entering it directly.

A more general solution would be to extend the
Nodes API (and also the Looks API) to have not
only the getNewTypes and getPasteTypes methods,
but also

public static final int ZERO = 0;
public static final int ONE = 1;
public static final int SEVERAL = 2;
/** please override me */
public int hasNewTypes() {
    return cardinality(getNewTypes());
/** please override me */
public int hasPasteTypes(Transferable t) {
    return cardinality(getPasteTypes(t));
private static int cardinality(Object[] x) {
    return x.length == 0 ? ZERO :
        x.length == 1 ? ONE :

with similar methods in Look, where ProxyLook
would merge as follows (operation is commutative
and associative):


NewAction and PasteAction could then query the
cardinality when deciding how to provide a menu
presenter, and in the case of SEVERAL call the
actual get*Types method only when the menu is posted.

AntProjectNode would then return SEVERAL for
hasNewTypes, of course.

Issue #35827 (JInlineMenu replacement) could help
as these actions could more cleanly change their
presenter each time they were displayed in a
parent JMenu (i.e. the main context menu, or the
Edit menu). In the case of SEVERAL, the action
should of course just create a JMenu presenter,
and defer adding menu items until getPopupMenu()
is called.

Open to argument which is most reasonable:

1. Live with the performance problem. In the case
of the Ant popup, it occurs only once per session
anyway. On subsequent popups, the NewType's are
created even when not needed, which is a moderate
waste of object allocation, but not much work
compared to running Ant introspection.

2. Work around in the Ant module only, by avoiding
NewType[]/PasteType[] results which rely on

3. This enhancement.
Comment 1 Petr Nejedly 2004-01-09 09:44:43 UTC
Taking over the node bugs from phrebejk.
Comment 2 Antonin Nebuzelsky 2005-04-25 15:52:16 UTC
Does this enhancement still make sense?
Comment 3 Antonin Nebuzelsky 2008-02-08 15:04:03 UTC
Reassigning to new module owner Tomas Holy.
Comment 4 Jaroslav Tulach 2010-04-06 18:08:59 UTC
If there were performance problems, we would see them reported by exception reporter. Do you have such snapshots indicating the problems somewhere?
Comment 5 Jesse Glick 2010-04-06 18:24:03 UTC
The originally reported use case applied to Ant structure editing, which was deleted a few years ago, so there would be no snapshots of this. I would expect any other Node's with expensive get{New,Paste}Types implementations to have the same problem, though it might not exceed the 3000msec threshold.