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

Sun Apr 17 00:13:00 GMT 2005

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
>