This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
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.
I tried with Eclipse + Weblogic and got following error on server console:
Unable to deploy EJB: sims.ejb.TestSB
Cannot inherit from final class
Cheers,<br />Chandrashekhar <br />SCJP
Joined: Aug 05, 2006
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.
Joined: Aug 26, 2006
there was no compilation error as such but when i started server i got the Exception on server log, which i wrote in my pevious post.
Joined: Aug 05, 2006
Does that mean that the behavior is application server vendor specific. The spec only uses the words "MUST NOT" and does not say anything as to what will happen if a session bean is declared as final.
If you would have my other posts you would have noticed that I have found similar issues where the session beans are clearly violating the rules of Session Beans.
For Session Beans rules i have read EJB In Action 3.0 Application Server: JBOSS 4.2.3.GA
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...?