Of course the modification proposed here is not thread safe in its current form.
Jon.
On 7/30/08, Adrian Tarau <[EMAIL PROTECTED]> wrote:
> The best way to implement listeners (as you may see in
> EventListenerList) is to work with arrays.They are immutable and have
> the lowest memory footprint(instead of HashSet/ArrayList or any
> concurrent class).
>
> Eventually you can skip copying the listeners array if you manage
> everything locally instead of having a class like EventListnerList(need
> it - maybe - if you fire events at a really high rate, so you want to
> avoid creating an array every time). If you encapsulate array changes in
> a class ArrayUtilities you will not add to much code to implement
> add/remove/fire listeners.
>
> public class A {
>
> Listener[] listeners = new Listener[0] ;
>
> // add a new listener
> public void addListener(Listener listener) {
> listeners = ArrayUtilities.addObject(listeners, listener);
> }
>
> // remove a listener
> public void removeListener(Listener listener) {
> listeners = ArrayUtilities.removeObject(listeners, listener);
> }
>
> // fire event
> public void fireCodeChanged(Event event) {
> Listener[] currentListeners = this.listeners;
> foreach(Listener listener : listeners) {
> listener.onChange(event);
> }
> }
>
> Right now IntrospectorCacheImpl can fail with
> ConcurrentModificationExceptions if you don't add synchronized to
> addListener and removeListener.
>
> ....
>
> Nathan Bubna wrote:
>> Given the lack of affirmative response, i'm going to take some wild
>> guesses here...
>>
>> On Thu, Jul 24, 2008 at 10:34 PM, Nathan Bubna <[EMAIL PROTECTED]> wrote:
>>
>>> 1) Does anyone out there actually use custom implementations of the
>>> IntrospectorCache interface?
>>>
>>
>> nope.
>>
>>
>>> 2) Does anyone use any IntrospectorCacheListeners?
>>>
>>
>> no.
>>
>>
>>> 3) Can anyone give me a use-case for IntrospectorCacheListeners?
>>> (Henning?)
>>>
>>
>> yes, Henning, who is busy with other things. Henning, if you would
>> like these back, i'll replace them then. for now, i'm yanking them.
>> :)
>>
>>
>>> For those curious about my reasons for asking: i'm looking at
>>> IntrospectorBase and the classes above and seeing slight risk of
>>> ConcurrentModificationExceptions in the way listeners are handled.
>>> This would be trivially fixed by synchronizing the add/removeListener
>>> methods. However, i'm hoping to use more fine-grained synchronization
>>> in those classes that would require potentially more hassle than the
>>> risk. Loads of fun, ya know. So, if i find out the listeners are
>>> used w/o problems, i won't worry about it. If i find out they're not
>>> used at all and can't figure out what they're good for, then i would
>>> happily be rid of them. :)
>>>
>>> all input is welcome!
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
--
Sent from Gmail for mobile | mobile.google.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
