I have always been weary of IDEs and other programming tools that “do the thinking for you.” In the best of cases, they allow experienced coders to rise above the busy work and text pushing of adding getters and setters, refactoring and shuffling files around. They offer handy templates for starting projects and classes. They can help give uniform style and headers to files. They are extraordinary helpful. So I am not trying to push everyone back to emacs (if only I could), but I am going to tell a lot of people to stop hijacking the fast lane.
Problem is a lot of less experienced programmers use these tools as a crutch. The pick up the habits promoted by these tools and don’t really understand what is going on behind them. Then they exhibit the worst personality trait of developers, when questioned about a habit that they don’t really understand, they become fanatical to defend it.
Case in point, Eclipse puts a serialVersionUID in any serializable class. If the developer removes it, it gives them a warning. So every new job I find a whole nest of developers who are putting serialVersionUID all over the code.
What’s wrong with serialVersionUID, you ask? It’s a hack, plain and simple. It is usally deployed as a quick and dirty way to get around proper development. Worse about Eclipse is the fact that they are giant generated numbers.
I usually hear two excuses for adding a serialVersionUID to an object: performance and version control.
The performance benefits of serialVersionUID are a myth. Long story short, yes, Java will calculate a serialVersionUID at runtime if one is not provided. This is a heavy calculation involving hashing of the bytecode. However, most software, especially server-side software, will be serializing the same objects over and over again. The JVM does not calculate a new serialVersionUID each time, just once, the first time. So if your server can stay up hours, days, or even weeks; your optimization is negligible.
It does not make it faster to send the object over the wire, it does not make the marshaling or unmarshaling any faster. There is not gain after that onetime hashing of the bytecode.
Yes, you can use the serialVersionUID to give an object an explicit version. If you let the JVM do it for you, it is very exacting. Anything that changes the bytecode will cause a new serialVersionUID: changes to the source code, using different compilers, or even different compiler switches can all effect the bytecode. You can easily get into situations where you get class not compatible errors.
If you are in the server-side world, this screams sloppy work! Why are you developers all using different compilers and switches? Why are different jars deployed across the servers? The answer isn’t to fake it with serialVersionUID but to get you team all on a clean and standardized setup. Your bug list, QA team, and Sysadmins up at 3am fixing things will thank you for it.
Run Your Versions
If you are serious about controlling your servers, and it isn’t because you are too lazy to make sure that everyone is using the same setup; then go for it. But why does Eclipse give you that crappy:
serialVersionUID = 123871234768L;
Why not start at a sensible 1, or 100? When you come back a week later, are you going to notice that someone had to up the version to 123871234790L?
Also, off of the top of your head, what are all the changes to a class that may require a new serialVersionUID? The normal advice is, when in doubt, iterrate? I suspect that most developers who let Eclipse put that number there do not understand how to manage it themselves, which is what declaring it means you have to do.
If you start passing incompatable classes with the same serialVersionUID, your team is going to loose it when it tries to debug that one.