This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
javax.swing.event.EventListenerList java and GCJ implementations differ
- From: Andreas Grunewald <gruni dot ca at gmail dot com>
- To: java at gcc dot gnu dot org
- Date: Sat, 16 Apr 2005 21:50:09 +0200
- Subject: javax.swing.event.EventListenerList java and GCJ implementations differ
- Reply-to: Andreas Grunewald <gruni dot ca at gmail dot com>
Hey everybody,
I was finally able to get a version of my programm compiled with the
GCJ4, after removing all usage of regex and implementing my own little
logging framework.
But while testing I found something interesting.
I'm using javax.swing.event.EventListenerList the code of the JDK
implementation (EventListenerList.java 1.36 04/05/05) has the
following code in it's add method
171: if (listenerList == NULL_ARRAY) {
172: // if this is the first listener added,
173: // initialize the lists
174: listenerList = new Object[] { t, l };
175: }
so you see that the listenerList is instanciated with two Objects in
the array the Object t which is the type and the Object l which is the
actual listener. Because of this the general code for Classes using
the EventListenerList when fireing Events is:
protected void fireFooXXX() {
// Guaranteed to return a non-null array
Object[] listeners = listenerList.getListenerList();
// Process the listeners last to first, notifying
// those that are interested in this event
for (int i = listeners.length-2; i>=0; i-=2) {
if (listeners[i]==FooListener.class) {
// Lazily create the event:
if (fooEvent == null)
fooEvent = new FooEvent(this);
((FooListener)listeners[i+1]).fooXXX(fooEvent);
}
}
}
as one can see the for loop skips every second entry. Because this
entry is just the type descriptor for the actual Eventlistener.
Unfortunately when compiling my classes with GCJ the EventListenerList
only saves the actual EventListener and not it's type. Because of this
my Eventhandling code doesn't work anymore. Could someone please
comment on this why the implementation differes from the original Sun
Java one ?
Thanks,
Andreas
PS This is something I could change with yet another workaround, but I
think this is really a wrong implementation which should be fixed.