This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Because ActionForms are JavaBeans, subclasses should also implement Serializable, as required by the JavaBean specification. Some containers require that an object meet all JavaBean requirements in order to use the introspection API upon which ActionForms rely." (16Oct2004)
The ActionForm class already implements java.io.Serializable. Are not the subclasses extended from this class automatically serialized by inheritance? In other words, why implement serializable again?
Wow. Great question. I never noticed it before and it's right there in the ActionForm's javadoc.
Yes, if ActionForm is Serializable its subclasses implement Serializable.
Speople specify "implements Serializable" in bean subclasses as a gentle reminder. It's still weird that the Javadoc says that. Maybe it was intended as a reminder any non-Serializable class variable should be declared transient.
A good workman is known by his tools.
Joined: Jan 18, 2005
Thank you for acknowledging the question. The date on the JavaDoc is relatively recent, too. It is weird, and no one has a good answer; everyone I ask seems equally stumped, even my Struts instructor.
I can tell you that awhile ago a version of Tomcat I used threw a stack trace on shutdown and startup (only after the first time the app had been started) complaining that some of my ActionForm classes, which I had kept in session scope, were not serializable. I believe this had something to do with the way Tomcat tried to save and restore sessions; just a guess, I didn't really look into it too hard. Implementing serializable took care of the situation.