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 ?