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 32708 - Allow lightweight and simple Children
Summary: Allow lightweight and simple Children
Alias: None
Product: platform
Classification: Unclassified
Component: Nodes (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker (vote)
Assignee: t_h
: 38445 (view as bug list)
Depends on:
Blocks: 19484 35833 38445
  Show dependency tree
Reported: 2003-04-08 12:24 UTC by Jaroslav Tulach
Modified: 2008-12-22 13:36 UTC (History)
4 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
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
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* 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
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):


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