(Not So) Stupid Questions 8: serialVersionUID Blog

    (Not So) Stupid Questions


    Editor's note: Sometimes the most interesting discussions begin when someone says, "This may be a stupid question, but ...." If the person asking the question has taken the time to think about the problem before asking, the question is often not stupid at all. The uncertainty points out an ambiguity in the specs, holes in the docs, or a search for how more experienced programmers might address a particular problem. From time to time, we will print one of the "(Not So) Stupid Questions" we receive and invite our readers to answer the question in the feedback section.

    Remember that new people are joining the Java community all the time and may be looking for help from those with more experience. Also, those who began with Java as their first language can benefit from those coming to the community with experience in other languages. As always, answer the questions with kindness. You are also welcome to submit your questions to

    This may be a stupid question, but ... "What's the deal with serialVersionUID?"

    First thoughts:

    I understand that it is some sort of checksum of the class's name, members, methods, etc.

    I also understand that it allows the JVM to detect old or "incompatible" versions of classes being deserialized. But given that you can set it to some arbitrary value with seemingly no ill effects (in fact, Eclipse now warns you when you haven't overridden it), why bother checking at all?

    It is solely for detecting deployment issues where, for example, one node of a 40-node environment is still running the previous version? Or have I missed something more fundamental?

    And I guess my big question is:

    What can go wrong if you do override serialVersionUID?