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.
|Summary:||Allow lightweight and simple Children|
|Product:||platform||Reporter:||Jaroslav Tulach <jtulach>|
|Severity:||blocker||CC:||issues, jglick, phrebejk, pkuzel|
|Issue Type:||TASK||Exception Reporter:|
|Bug Depends on:|
|Bug Blocks:||19484, 35833, 38445|
Description Jaroslav Tulach 2003-04-08 12:24:03 UTC
I'd like to investigate the possibility to rewrite LookChildren to not use Children.Keys and their heavyweight infrastructure, but rather directly subclass Children and implement everything itself. For that I would like to move all possible garbage out from Children (notifyAdd, updateEntries, etc.). Moreover I'd like to investigate the possibility of rewriting Visualizers to not be needed.
Comment 1 Jaroslav Tulach 2003-04-08 12:33:01 UTC
openide has been branched as lightweight_32708 rooted at BLD200304080100
Comment 2 Jaroslav Tulach 2003-05-28 13:24:01 UTC
Maybe this could be merged into trunk as it makes the Children more readable and allows (after removing all the final keywords) completely different implementation. What do you think Hrebejk?
Comment 3 Jesse Glick 2003-05-28 17:06:50 UTC
IMHO if we use Looks over Nodes, we need to do some work like this to reduce memory overhead. If you look at heap size after creating a bunch of raw Look tree nodes vs. creating LookNode's, there's a huge difference - something like a factor of 10 more memory used when constructing Node's. Probably some of that is in Children.Keys - not sure, but it's not hard to find out with a profiler. Just run 'optit' target of performance/threaddemo/build.xml, use Look Nodes, expand some folder with 10k children, then look for any classes with >=10k instances.
Comment 4 Jaroslav Tulach 2003-05-28 18:15:19 UTC
It should not be hard to unfinalize methods in Children and implement simple LookChildren (without change notification) directly and see the improvement.
Comment 5 Jaroslav Tulach 2003-09-01 08:43:08 UTC
Instead of last comment to unfinalize some methods in getChildren (which would mix api and spi), the prefered way is to introduce new factory method: public static Children NodeOp.createFromList (List nodes); that would create the lightweight impl of children (without any Entry, Info, etc.) just delegating to the provided List. The creator of such list would then be responsible for firing correct events via Node.fire*Node* methods.
Comment 6 Petr Nejedly 2004-01-09 09:44:33 UTC
Taking over the node bugs from phrebejk.
Comment 7 _ pkuzel 2004-05-07 19:06:36 UTC
Even better introduce interface Children.Interface (that will be implemented by all current Children subclasses). Required methods: getNodes(), getNodesCount(), addChildrenListener() <new one>
Comment 8 _ pkuzel 2004-05-07 19:09:04 UTC
*** Issue 38445 has been marked as a duplicate of this issue. ***
Comment 9 _ pkuzel 2004-05-07 19:10:35 UTC
Duplicatte added value excerpt: I though about implemeting my own children but I have not found any way how to notify about change. There is probaly some package private contract.
Comment 10 _ pkuzel 2004-05-08 23:55:31 UTC
Well, getNodes() would not allow to write scalable code either. So it's better to copy DOM's NodeList interface (or CharSequence) and have following Children.Interface methods: int getNodesCount(); Node nodeAt(int index); It allows a view (consumer) to ask only for nodes it really needs to visualize. No big Node array must be held in memory. Events can be addressed by testing for being an instance of Children.EventSource class (inspired by DOM too): addChildenListener(l) removeChildrenListener(l) where the ChildrenListener interface is like: void chidrenEvent(e) and the ChildrenEvent is (inspired by BeanContextMembershipEvent): // is there a change in given range boolean changeInRange(int lowInclus, int hiExclus); // new children size (to detect removal/insert) int sizeAfterChange(); // no need one can ask source directly // and optional method that can be added later on: // changed indexes (insert at 0 returns very long array) int indexes(); Just my 2 bytes.
Comment 11 Jesse Glick 2004-05-09 02:11:52 UTC
I think the issue_35833 branch already has a very similar API.
Comment 12 Antonin Nebuzelsky 2008-02-08 15:02:28 UTC
Reassigning to new module owner Tomas Holy.
Comment 13 Jaroslav Tulach 2008-02-11 14:20:33 UTC
LookChildren are gone. Btw. another approach for something lightweight was made as part of issue 46900