• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Quick question - serialization

 
Dawid Skrzypczynski
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I use serialization for my swing class and deserialization process doesn't not return ActionListener for my button.

That the ActionListener is default marked as transient ?
 
Ove Lindström
Ranch Hand
Posts: 326
Android Firefox Browser Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Campbell Ritchie
Sheriff
Posts: 48381
56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 48381
56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ove Lindström knoiw more about it that I do
 
Ove Lindström
Ranch Hand
Posts: 326
Android Firefox Browser Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Matthew Brown
Bartender
Posts: 4565
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ove Lindström
Ranch Hand
Posts: 326
Android Firefox Browser Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Matthew Brown wrote:
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.

Honorable Dr. Kabutz did it in 2001. (See http://www.javaspecialists.eu/archive/Issue013a.html)
 
Dawid Skrzypczynski
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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

mainClass:

swingClass:


Conclusion is that the ActionListener is probably default transient.

I have last question what is the difference between

and

 
Ove Lindström
Ranch Hand
Posts: 326
Android Firefox Browser Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dawid Skrzypczynski wrote:

I have last question what is the difference between

and



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.
 
Campbell Ritchie
Sheriff
Posts: 48381
56
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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."
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic