Instead of responding with stuff woven out of your mind, you could read the specs carefully. Section 24.1.2 "Programming restrictions" discusses this and gives reasoning for them:
. An enterprise Bean must not use read/write static fields. Using read-only static fields is allowed. Therefore, it is recommended that all static fields in the enterprise bean class be declared as final. This rule is required to ensure consistent runtime semantics because while some EJB Containers may use a single JVM to execute all enterprise bean's instances, others may distribute the instances across multiple JVMs. . An enterprise Bean must not use thread synchronization primitives to synchronize execution of multiple instances. Same reason as above. Synchronization would not work if the EJB Container distributed enterprise bean's instances across multiple JVMs. Also, some comments of my own: At a low level, Java's instance(non-static) methods receive implicitly the this object as the first parameter. The 'this' keyword is automatically added in the code where it's implicit by the compiler(just as C++ internally works). See the JVM specification for details. Also, you may code static methods in your EJB class. They would never be exposed though, as interfaces (to your bean) cannot include the signatures of those methods. See the Java Language specification for details. Your response implies that static methods would need to interact with a particular bean instance. That doesn't necessarily break the EJB spec, but it's a shameful programming practice. EJBs, even Entity Beans are fully blown business objects. The facade pattern is quite useful, but it seems most programmers think all business logic belongs in these and Entity Beans are just an excuse not to write JDBC code. Don't break encapsulation just to use facades; I mean the complete definition of encapsulation: An object should expose its state as little as possible(without being a fundamentalist of OOP). The question should be: Which purpose should a static method serve? A - If it is a utility method, then it probably could also be placed in a regular java class. B - If it is geared towards managing the lifetime of objects of that class, then it is either superceeded by the Home interfaces or not applicable or even undesirable(for singletons, for instance). I honestly doubt there are many other uses for static methods that aren't directly related for these two, but I'm open to comments. The bottom line is: EJB Containers abstract some concepts such as instance lifetime and load distribution. That makes EJBs easier to write and maintain. That also makes static and/or synchronized directives superfluous(Except when defining constant fields, using 'static final'). My 2c, Juan Pablo Lorandi Chief Software Architect Code Foundry Ltd. [EMAIL PROTECTED] Barberstown, Straffan, Co. Kildare, Ireland. Tel: +353-1-6012050 Fax: +353-1-6012051 Mobile: +353-86-2157900 www.codefoundry.com > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]] On Behalf Of Aashish Kaushik > Sent: Saturday, September 28, 2002 9:22 AM > To: [EMAIL PROTECTED] > Subject: ejb method signature-Why Cant EJB methods be > static-Group Plz. Contribute > > > Hello All , > > This seems to be a good question raised by Javed and i would > appreciate if everybody would contribute in his quest for the > answer. I Reframe the question with a bit of my own personal > query added to it. > > I make it clear now that whatever i answer to the question > framed below is purely woven out of my mind and has nothing > to do with the specification . > > Any Corrections are welcome. > > Question : Why cant ejb methods be Static ?? > > Answer : Static methods could be declared in Beans but since > in static methods we dont have the Refernce to the Object who > called the method (Since the use of "this" is strictly > prohibted) so that would involve the extra > work of looking up the bean and executing the methods on its > fields. Which is quiet opposed to Object methods which have > the reference of the Stub or Remote Refernce and hence > doesnot have to lookup the object ,which in turn saves the > extra overhed of looking up the concerned bean as was in the > case of static methods of the Bean Class. > > > > Javed as far as your answer of Synchronized methods in Beans > is concerned ,There is no need for methods to be declared > synchronized as its EJBObject who can receive multiple calls > from the clients on the same methods. But in order to > maintain concurrency EJB OBject passes the call to the Bean > methods one at a time. So the need of synchronized methos > doesnot arises. > > Regards, > Aashish > > ************************************************************** > *********************************************** > > Hi > > Is there any restrictions on the method signature of ejb > methods like it should not be static and synchronized. Is > there any article on the restrictions of signatures in ejb methods > > regards > javid > > ============================================================== > ============= > To unsubscribe, send email to [EMAIL PROTECTED] and > include in the body of the message "signoff EJB-INTEREST". > For general help, send email to [EMAIL PROTECTED] and > include in the body of the message "help". > > ============================================================== > ============= > To unsubscribe, send email to [EMAIL PROTECTED] and > include in the body of the message "signoff EJB-INTEREST". > For general help, send email to [EMAIL PROTECTED] and > include in the body of the message "help". > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
