Re: javax.swing.event.EventListenerList java and GCJ implementations differ

[Andreas Grunewald <gruni dot ca at gmail dot com>]

Well thing is the API for EventListenerList has code that should be
used when one wants to fire Events, and the reason why I posted the
code was because I wanted to verify the JDK behaviour. but if you
don't want code to show that there might be something wrong then I
need to take the API Documentation which says
[quote]
getListenerList

public Object[] getListenerList()

    Passes back the event listener list as an array of
ListenerType-listener pairs. Note that for performance reasons, this
implementation passes back the actual data structure in which the
listener data is stored internally! This method is guaranteed to pass
back a non-null array, so that no null-checking is required in fire
methods. A zero-length array of Object should be returned if there are
currently no listeners. WARNING!!! Absolutely NO modification of the
data contained in this array should be made -- if any such
manipulation is necessary, it should be done on a copy of the array
returned rather than the array itself.
[/quote] from:
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/event/EventListenerList.html#getListenerList()

So it says in the Documentation "pairs" so it can be that the returned
Object has only one entry. Th reason why I didn't file a Bug report
right away was because a) I didn't know how and b) I didn't know if I
misunderstood something or if there was a valid reason for the code of
GCJ to behave like it does. The 4 lines of code from the JDK where
just to visualize my point not to get someone to actually implement
this code.

Regards,

Andreas

PS I filed it as Bug 21065

16 Apr 2005 14:57:49 -0600, Tom Tromey <tromey@redhat.com>:
> >>>>> "Andreas" == Andreas Grunewald <gruni.ca@gmail.com> writes:
> 
> Andreas> I'm using javax.swing.event.EventListenerList the code of the JDK
> Andreas> implementation (EventListenerList.java 1.36 04/05/05) has the
> Andreas> following code in it's add method
> 
> Please don't post code from the JDK on this list.  We are a cleanroom
> reimplementation -- not only do we purposely avoid reading the code of
> the JDK, we don't accept non-trivial code contributions from people
> who have done so.
> 
> It is better to just send bug reports mentioning the behavior you
> expect, and what you saw, and why you think the current state is
> incorrect.
> 
> Tom
>