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.
openide has been branched as lightweight_32708 rooted at BLD200304080100
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?
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
It should not be hard to unfinalize methods in Children and implement
simple LookChildren (without change notification) directly and see
Instead of last comment to unfinalize some methods in getChildren
(which would mix api and spi), the prefered way is to introduce new
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
Taking over the node bugs from phrebejk.
Even better introduce interface Children.Interface (that will be
implemented by all current Children subclasses).
getNodes(), getNodesCount(), addChildrenListener() <new one>
*** Issue 38445 has been marked as a duplicate of this issue. ***
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
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:
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:
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)
Just my 2 bytes.
I think the issue_35833 branch already has a very similar API.
Reassigning to new module owner Tomas Holy.
LookChildren are gone.
Btw. another approach for something lightweight was made as part of issue 46900