That is correct. You do not need to send the ActionListener to the receiver since that is not part of the data structure. When the receiver creates a new instance of the class for "de-serialisation", it should create a listener.
A "real life" example would be if you asked someone else to monitor your server for you. You would send the current ip of the server and the credentials, but not the actual running monitor program.
That sounds unlikely. Unzip the file called src.zip in your standard Java™ installation folder and go to javax→swing→AbstractButton and see whether the Listeners are transient or not.
How are you adding the Listener to the Button? Is it in the constructor? You know you ought to be using Beans rather than serialization for Swing components? Would that make any difference? I don't know myself.
Campbell Ritchie wrote:Ove Lindström knoiw more about it that I do
Maybe, maybe not.
I just lean on the quote from the javax.swing part of the API
"Warning: Serialized objects of this class will not be compatible with future Swing releases. The current serialization support is appropriate for short term storage or RMI between applications running the same version of Swing. As of 1.4, support for long term storage of all JavaBeansTM has been added to the java.beans package. Please see XMLEncoder."
and the fact that Swing is MVC-based so the only thing that should be serialized, in my humble opinion, is the model (implemented as beans) is the thing to serialize. I would say that creating a new instance of a listener, if it is stateless, would be faster than de-serialize it.
Ove Lindström wrote:and the fact that Swing is MVC-based so the only thing that should be serialized, in my humble opinion, is the model (implemented as beans) is the thing to serialize.
That's what I was thinking. I'm struggling to think of a situation where I'd want to serialize a graphical component and/or listeners. Sounds like asking for trouble.
Well, actually, I have done that. We had a server that needed to send out updates of information to "dumb-clients" and the nature of the information gathering was such that the server side did not want to put ANY logic at all that was not controlled by them on the clients.
We ended up wrapping the components and sending them across the network to the monitors.
I don't know that is good way but i do something like this.
I skipping part where i am saving this object to file and part where i am checking that the file exist etc. Saying otherwise the object is already saved and the button ok has listener so now it should be possible to read him.
this is just example.
I have two class: mainClass and swingClass
I have last question what is the difference between
First one is a "quite unique" version number that tells the decoding side what class byte code you used. Should be re-generated whenever a serialized class is being changed in such a way that the receiving part must be updated to be able to use it. If the receiving part needs to update to a newer version of your jar-file, then the serialVersionUID should be changed.
When you use the 1L value, you state that "I don't really care" and I think that you override some of the serialization checks but I'm not sure.
That is actually why you find the warning about Swing-version mentioned above.
Joined: Oct 13, 2005
You are right about the SUIDs if the class changes. If the class changes in such a way that the SUID changes, it will only be possible to serialise and de-serialise objects to the same class version. If you write 1L, then you are saying, "I want this regarded as version 1 for ever."