At 04:41 PM 3/5/2001 +0100, Kleopatra wrote:
>"Wathen, Dave" schrieb:
> >
> > I agree with Paul this shouldn't be happening. Do you have a
> > reference to the table in your subclass of AbstractTableModel
> > (either directly or indirectly). The listeners are transient
> > references.
> >
>
>Why do you think they are transient?
>
>Here is the listenerlist declaration of AbstractTableModel
>
> /** List of listeners */
> protected EventListenerList listenerList = new EventListenerList();
>
>And here is the actual storage in EventListenerList
>
> protected transient Object[] listenerList = NULL_ARRAY;
>
>true, it's transient, but only to be able to write all the listeners
>manually to the objectoutpstream in case some of them are not
>serializable:
>
>[code snipped]
>
>In total: every listener is serialized to the outputstream....
Every -serializable- listener, that is.
Your post did tell me something I wasn't aware of, but should have
realized: while EventListeners aren't serializable, Java will attempt to
save an EventListener object if it implements java.io.Serializable in
some other way. JTable is such a case.
By the way, here's a link to an explanation as to why EventListeners
are not serializable by default. I've found it useful for back reference
on multiple occasions.
http://developer.java.sun.com/developer/bugParade/bugs/4031001.html
WRT to the original problem, I'm leaning more and more toward
recommending a special method for saving only the data in an
AbstractTableModel subclass, unless there's no chance that the
subclass will ever be re-used.
I haven't had much experience yet with beans, but your solution
looks okay, so long as nothing assumes that any instance of
ATM is following the usual scheme for listeners. (That is, no
outside code assumes it can check whether a particular JTable is
listening to a particular ATM, for example.) I'd say that 95% of the
time, this will not be a problem, but again, I haven't wrangled around
event listeners enough to know for sure.
>To solve the original problem, I implemented the actual
>adding/removing/notification of TableModelEvents inside a class
>TableModelSupport (in analogy to PropertyChangeSupport in java.beans)
>and let my custom table model have a transient variable to that support.
>Now it's possible to use fine grained control about which listeners are
>written and which are not. Don't forget to initialze the support on
>readObject(). If the custom derives from some AbstractTableModel (I
>often customize DefaultTableModel) then make sure to overwrite
>add/removeTableModelListener/fireTableChanged(TableModelEvent e) to
>delegate to TableModelSupport.
_______________________________________________
Advanced-swing mailing list
[EMAIL PROTECTED]
http://eos.dk/mailman/listinfo/advanced-swing
