This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
Why not? It is probably more for documentation purposes than anything else - ie just so the javadoc will explicitly state it, rather than the reader having to KNOW that it extends a class that implements serializable.
Because Serializable is a marker interface, any class that is indeed serializable should include this interface in its class declaration.
I can create a class with all, boring Java data types and call it serializable. Then I can subclass it and add an instance variable that is of type DataSource or DatabaseConnection, which isn't declared as being transient, and isn't serializable. In this case, I have extended a class that IS serializable, but my own class is indeed NOT serializable.
Does that make any sense?
By the way, if you extended a Serializable class, but added instance variables that weren't Serializable, would you be a "serial killer?"
I'm not satisfied with the above answers There must be a decent reason to decide to set this class Serializable. Servlets are not supposed to hold states, so I can't understand either why it has to be Serializable. Any relation to distributed environments ?