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.
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 : SEVERAL; } with similar methods in Look, where ProxyLook would merge as follows (operation is commutative and associative): ZERO + ZERO = ZERO ZERO + ONE = ONE ZERO + SEVERAL = SEVERAL ONE + ONE = SEVERAL ONE + SEVERAL = SEVERAL SEVERAL + SEVERAL = SEVERAL 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 introspection. 3. This enhancement.
Taking over the node bugs from phrebejk.
Does this enhancement still make sense?
Reassigning to new module owner Tomas Holy.
If there were performance problems, we would see them reported by exception reporter. Do you have such snapshots indicating the problems somewhere?
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.