Use the serialVersionUID or suppress warnings?

views:

3182

answers:

+13 Q:

Use the serialVersionUID or suppress warnings?

Dear all,

first thing to note is the serialVersionUID of a class implementing Interface Serializable is not in question. What if we create a class that for example extends HttpServlet? It also should have a serialVersionUID. If someone knows that this object will never be serialized should he define it or add an annotation to suppress those warnings?

What would you do and why?

Thanks for sharing your thoughts.

Okami

+2 A:

Let Eclipse generate an ID. Quick and easy. Warnings are not to be ignored. Also saves you lots of trouble should you ever come to the point where the object /has/ to be serialized.

xmjx 2008-09-28 20:52:52

I disagree. The ID in this case is useless clutter. This warning should, in my opinion, be suppressed.

skaffman 2008-09-28 20:53:59

Warnings are a prompt asking you to make an informed decision, not instructions that are to be blindly followed.

McDowell 2008-09-29 10:23:32

+4 A:

If you do not plan to serialize instances, add a SuppressWarning.

A generated serial ID can be a bit dangerous. It suggests that you intentionally gave it a serial number and that it is save to serialize and deserialize. It's easy to forget to update the serial number in a newer version of your application where your class is changed. Deserialization will fail if the class fields have been changed. Having a SuppressWarning at least tells the reader of your code that you did not intend to serialize this class.

Bno 2008-09-28 20:58:12

+8 A:

I don't know Java best practices, but it occurs to me that if you are claiming that serialization will never happen, you could add a writeObject method which throws. Then suppress the warning, safe in the knowledge that it cannot possibly apply to you.

Otherwise someone might in future serialize your object through the parent class, and end up with a default serialized form where:

the form isn't compatible between different versions of your code.
you've suppressed the warning that this is the case.

Adding an ID sounds like a bodge, since what you really want to do is not serialize. Expecting callers not to serialize your object means that you expect them to "know" when their HttpServlet is of your class. That breach of polymorphism is on your head for having a Serializable object which must not be serialized, and the least you can do is make sure unwary callers know about it.

Steve Jessop 2008-09-28 21:12:12

I think it's a lot of overhead but in a professional environment this seems quite necessary.

Okami 2008-09-28 21:52:48

Just want to second the motions that you make sure you prohibit serialization (ie with an exception) if you aren't going to support it.

cynicalman 2008-09-28 23:33:13

I would not go through the trouble of preventing serialization from ever happening. Just don't declare a SVUID, which means that each compile a unique one will be generated; making serialization unreliable but not breaking applications which depend on it, inadvertently.

Justin 2010-05-14 03:38:04

That warning drives me crazy, because every time you subclass a Swing class, you know you're never going to serialize it, but there is that stupid warning. But yeah, I let Eclipse generate one.

Paul Tomblin 2008-09-28 21:29:06

true that, whats worse, you cannot add suppress warning to a package!

Justin 2010-05-14 03:32:47

+3 A:

I refuse to be terrorized by Eclipse into adding clutter to my code!

I just configure Eclipse to not generate warnings on missing serialVersionUID.

ykaganovich 2008-09-28 21:35:23

I think that add @suppressWarning and throw exception when you do not support serialization is the best approach in a professional evironment. Your IDE to remembers you of serialization may be important in much cases.

Tom Brito 2010-03-06 23:21:02

+3 A:

Even if you know this object will be serialized there is no need to generate serialVersionUID because java will automatically generate it for you and will automatically keep track of changes so your serialization will always work just fine. You should generate it only if you know what you are doing (backward serialization compatibility, manual change tracking etc.)

So I would say suppressing the warning is the best and safest solution in most cases.

serg 2008-09-28 21:55:46

if you want to serialize something, you should always provide an explicit version value (1, 2, 3, ...). This allows you to tell Java serialization when compatibility is broken. For example, if all you're doing is adding fields, it can still read old .ser files with the same version.

Scott Stanchfield 2008-09-29 19:46:46

+3 A:

If you leave out a serialVersionUID java will generate one for the class at compile time (it changes with every compilation).

When deserializing objects the serialVersionUID of the deserialized object is compared to that of the class in the jvm. If they are different they are considered incompatible and an Exception is thrown. This can happen for instance after upgrading your program and deserializing old classes.

I always use 1L for serialversionUID. It doesn't hurt (compared to the default generated) and it still leaves the option of breaking compatibility later by incrementing the id.

Glever 2008-09-29 09:59:41

A serial version UID member is not added to classes at compile-time. If it is missing, it is computed from the member signatures of the class at runtime. It only changes when the signatures change, not necessarily with every compilation.

erickson 2008-09-29 17:37:41

+2 A:

It is good to generate SVUID to every class implementing serializable. The reason is simple. You never know when it will be serialized by you or by some 3rd party. There can be configured a lot of services which will serialize servlets. For every IDE exists plugin which generates one or just use template and set svuid = 1L.

Rastislav Komara 2008-09-29 14:02:31

I'm not so sure about that.. If you add the SVUID it´s good to see what are you letting serialize. It can cause security problems if a client can get a password field by serializing your whole program.

Tom Brito 2010-03-06 23:26:51

Generating SVUID in Serializable classes has nothing to do with serializable fields. Of course, you should pay attention to which fields are serialized.

Rastislav Komara 2010-03-10 13:34:14

If you generate a SVUID of 1 for example, then change the layout of your class that now means you must maintain SVUID (and update to 2). Most people won't maintain this. This is unnecessary if you don't intend the class to be serialized.

Justin 2010-05-14 03:36:51

"SVUID to every class implementing serializable" If class is serializable there is always someone in the world who wants to serialize it. In general, my target was not to solve people's laziness.

Rastislav Komara 2010-05-19 12:39:33

Please follow this link to get detailed explanation: http://technologiquepanorama.wordpress.com/2009/02/13/what-is-use-of-serialversiouid/

harshit 2009-03-17 17:23:22

Thanks @ Steve Jessop for his answer on this. It was 5 lines of code... hardly a hassle.

I added @SuppressWarnings("serial") just above the class in question.

I also added this method: private void writeObject(ObjectOutputStream oos) throws IOException { throw new IOException("This class is NOT serializable."); }

Hopefully that's what Steve meant :)

Mike 2010-05-14 03:24:32

ansaurus

tags:

views:

answers:

Use the serialVersionUID or suppress warnings?

related questions