• Post Reply Bookmark Topic Watch Topic
  • New Topic

Unable tp override serialVersionUID

 
Chad Clites
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am attempting to pass a JFrame from a servlet to an applet by using an ObjectOutputStream. The code that I am using is simple enough; It will pass a String just fine.

For now, I am just trying to pass an empty JFrame. When I run the applet, I get an error that at first glance seems to indicate that I am using one jre to compile the application, and another to run it.

java.io.invalidClassException; javax.swing.JComponent: local class incompatible; stream classdesc serialVersionUID = 7917968344860800289, local class serialVersionUID = 8258372400816541186

Again, I assumed I was getting the error because of clashing libraries. I went ahead and verified that I am using the same jre version for both. I have used the serialVersionUID field before, so I created a class that extended JPanel, and added private static final long serialVersionUID = 7917968344860800289L; as a field, then tried to pass that through, but I got the same error (with the same serial numbers, which seemed odd...). I tried using the local class serialVersionUID, but that didn't work either.

I looked through the Serialization API, as well as the Java Object Serialization Specification. Admittedly, I have not got through all 90 pages or so of the specifications yet. Do I need to pass a parameter to the ObjectOutputStream so that it uses my suid instead of generating it's own? OBviously, at least to me, the streams are working properly because I can pass Strings just fine.

Back to the excitement of the Java Object Serialization Specification.

EDIT: I forgot to include the applet code that reads the input from the stream:

Edit 2: I think I may have resolved this on my own. According to the JPanel API, the expectation is that JPanel will not be compatible across different versions of Java. So I changed the JPanel to a Panel, and it seemed to work just fine. (I didn't get any errors anyway). I'll try to add an image to the panel and pass that back. Two conclusions; the JVM must not have been using the same version of Java, and stay away from swing if I want to maintain compatibility across versions.
[ June 05, 2007: Message edited by: Chad Clites ]
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
serialVersionUID is not inherited in the way you think.

(Of course, the inheritance of the serialVersionUID field itself is exactly the same as of any other field. I'm talking about its effect on serialisation).

The serialVersionUID field of a particular class only affects the serialisation and deserialisation of the fields of exactly that class. It has no effect on the serialisation of the superclasses or subclasses.

So, you can't "override" the serialVersionUID of the Swing class by using a subclass.
 
Chad Clites
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That makes sense. Any libraries included would also have to be hashed. I had not thought of that, even though it makes perfect sense now. Is my presumption correct then that if I add Swing components to a custom class, and make that custom class serializable, I'll still have issues with the Swing components not being de-serialized properly?
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!