i was just playing arround with jme modifying it to use LinkedList instead of ArrayList (want to see what the performance difference is - my program does a lot of dynamic node addition and removal, and i want to see how big the impact on memory usage is) and i noticed that the return value of Node.detachChild() is not used anywhere. So (if noone uses that value) maybe it would make sense to change the return value to void in order to avoid data being pushed arround for no reason. I also noticed that detachChildAt() and detachChildNamed() are not used any where in the engine…
Maybe they are used in applications… - it won't get you any performance gain anyway (e.g. that 'data being pushed around' can be optimized away by hotspot).
Just because methods are not used internally by the engine doesn't mean that users shouldn't be able to use it. The impact of returning that int is very minimal (a normal remove would also have to search through the ArrayList to find the object to remove) . detachChildAt is currently used by detachChild and other methods. detachChildNamed is used by people who work with Nodes based on names.
In fact, you're right, for better perfomance in many cases it'd be best to extend Node and use your own type of collection. If you do lots of removing (escp with Nodes that have many childeren) I'd advice making an implementation that uses LinkedHashSet. I wouldn't worry much about memory impact, which will always be small compared to geometry buffers, and even the meta data of geometry objects.
ArrayList is used cause it's pretty much the fastest for rendering (no iterators), once you have all objects attachted, and it's still efficient enough when adding/removing a reasonable number of objects.
just thought it's better to say that than keep it only for me. i did not knew that the jit compiler makes the bad int go away 
edit:
my motivation for trying the linked lists was the duration of the removal operation for array lists (and the additional memory costs):
http://jamesthornton.com/eckel/TIJ-3rd-edition4.0/TIJ313.htm#Heading12933 (the table)
but as jme does mostly read operations on the nodes, the array list might still be the best for most cases.
i understand the reason why jme uses array lists.
about the link: the LinkedHashSet is in the "Sets" category on that page (where it is compared to other Set implementations - no Set and List comparison).
Yes, that's why I said they don't compare LinkedHashSet in the "List" section. Which they should, even if it doesn't implement the List interface.
Oh, and I wasn't trying to explain why jME uses ArrayList, I was -ever so subtle- trying to make you do a Node implementation that uses LinkedHashSet (rather than LinkedList), cause I was going to do that myself some time anyway
llama said:
I was -ever so subtle- trying to make you do a Node implementation that uses LinkedHashSet (rather than LinkedList), cause I was going to do that myself some time anyway :)
grrr, you manipulative llama }:-@