ConcurrentLinkedQueue in RenderableLayer

[jas511]

Is there a particular reason that RenderableLayer users a ConcurrentLinkedQueue? Is there actually thread safety needed there?

I ask because it would be nice to use a list so we could add renderables to either the beginning or the end of the list.

[tag]

While it's not recommended, some apps add and remove renderables on threads other than the EDT. Use of ConcurrentLinkedQueue is intended to reduce the likelihood of problems caused by that. To simulate list behavior, I suggest you subclass RenderableLayer and add a method that provides list-like behavior.

[jas511]

Thanks. I think at this point getting the list behavior would be more difficult than its worth. Since renderables is internal to RenderableLayer, we really can't change the behavior. We could add a different variable to our subclass but there is no guarantee that RenderableLayer wouldn't still try to use its internal renderables variable (especially as implementations of worldwind change). The safest bet would probably be to create a subclass of AbstractLayer that is similar to RenderableLayer - though I don't like this idea because it would have a lot of duplication.

There is always the options to modify the source to use a list since we're not trying to access them off the EDT, and now that I know that's the reason, it wouldn't be too hard to change that and add list behavior.

[tag]

What I meant was that you could subclass a layer that implements indexed insert and remove methods by manipulating the current queue. insert would create a new queue that's a copy of the old one with the new Renderable(s) inserted. Likewise for remove. This could work okay if the frequency of calls to insert and remove was relatively low. This would essentially implement the behavior of CopyOnWriteArrayList.

Alternatively, I've just declared the current queue to be protected (it was private) so you could set the list to be whatever you want in a subclass' constructor, and add your indexed insert and remove operations to that subclass. It's declaration, Collection<Renderable>, does not require a thread-safe collection. I haven't tried this, but I don't see off-hand any problems with it.

[jas511]

Thanks. Currently we are doing something similar to the first approach to simulate list behavior, but if you've noted, performance can be tricky. With your new changes, we should be able to use a list instead. Thanks for the quick reply.