They are trying to convey here that "You should not make the class as final as a good practice" infact even if you make final there will not be any error but you may not be able to subclass it because of "final"...i think it is just like a good practice/design ........ I dont think think there is any EJB Container which will throw the error if you make class as final , if it does then it is contradicting with Java concepts... It will throw error only when you try to subclass the "final class" (using extend keyword)...i hope i am clear in this explanation
I tried in NetBeans6.5+GlassFishV2, it works if a stateless session bean declared as final.
I don't think "must not" means "you'd better". NetBeans burst a warning massage "EJB cannot be final", unfortunately the bean still compiled and works. I prefer treating it as immature of the container like GlassFish.
By the way, I wanna know why EJB must not be final since it can works as final.
Appreciate your responses. The specs clearly states bean class "MUST NOT". I want to know what are the consequences of doing so? Is the consequence vendor specific. I am using notepad+JBOSS, I did not receive any warnings or errors or exceptions @ compile or runtime.
Just wanted to say thanks to everyone for the answers in this thread.
I was just reading p78 myself, thought "wonder why not final...?" then found this thread.
I can understand the bit about being public, having a no arg constructor, not being abstract... as each of these things could prevent the container from instantiating your bean. But final?
I read this thread as saying "the spec says MUST NOT", but I'm still not clear as to why - unless it is just "good practice"?
Why stop there - why not mandate in the spec that we must also comment our beans...?