I think the reason is simply to enjoy the benefits of inheritance. If you want to make another bean which has similar properties as a current bean except some additional methods then inheriting the existing bean makes life easy. Also remember class inheritance is possible in beans but inheriting the beanness is not yet allowed. See HFE Pg 186.
"Java Xml" and "Sudhir", Thanks for joining JavaRanch, but could you take a quick look at the naming policy and edit your profile accordingly. Sudhir, the reason I included you in this message is that we require both first and last names.
The important thing to remember with the EJB spec is that it is designed not just for programmers writing apps (bean providers), but also for container vendors. With Sun's approach to java we are living in an object-oriented world, which means object-oriented development options should be available to the container vendors. Consider the following remote component interface and stateful session bean implementation class:
Amongst the various things the container needs to do is create an EJBObject to mediate access to the bean instance. The spec doesn't mandate how this is done, but a possible solution for stateful (not stateless) session beans would be for the container to generate a class at deployment time like:
Inheritance in this case would be used as a code sharing mechanism. Sometimes that isn't a great approach, but you could make a reasonable case that this use of it wouldn't seriously violate LSP (liskov substitution principle). Of course, bottom line, the practical answer is "you don't use finalize because the spec says not to, and the spec is the agreement everybody has in common". [ February 07, 2004: Message edited by: Reid M. Pinchback ]