Why does HttpServlet implement Serializable?

Solution 1:

Technically, I believe the servlet container is allowed to "passivate" the servlet object to disk, in a similar way that EJB session beans can be. So you're correct to ask the question if your app will fail due to non-serializable fields.

In practise, I've never heard of a container doing this, so it's really just legacy baggage from the bad old days of early J2EE. I wouldn't worry about it.

Solution 2:

HttpServlet should by serialized to disk and survive restart of servlet container. For example tomcat allows you to set up flag which enable this kind of survive. The next option is transfer using JNDI. This is not garbage, it is used only in extreme use cases.

Solution 3:

Google seems to suggest that this was done so that container authors can have the option, if they want it.

You're correct that the servlet should hold no session-specific members, in fact I would think you'd want as little state at all as possible. If you store everything in either Session or ServletConfig, I think you'd be able to survive serialization.