Dear Juan ,
It was nice getting in to a discussion with you and some of your points
have sure added a bit to my knowledge
as well.
So Thanks again Juan.
I would like to add to the comment provided by you
<Juan>
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.
</Juan>
<Aashish> As far as Core Java Objects are concerned they behave the same
way as you have mentioned above.
but as far as EJB are concerned will not that break the very purpose of
EJB's
i.e beans talk to each other through Remote Interface and doesnot involves
in any way the object themselves
so the "this" keyword wont be availble to the beans accessing Distributed
objects.
I have O'Reilly to suppoprt my statement
</Aashish>
Aashish Kaushik
Software Engg.
TEL : 0120-4777881(Extn. 2390)
Cell : 9810744076
E-MAIL:[EMAIL PROTECTED]
Visit Us At : www.jilit.de
~~~~~~~~~~~~~~~~~~~~~~
There are no great people in this world,
only great challenges which ordinary
people rise to meet.
- William Frederick Halsy, Jr.
~~~~~~~~~~~~~~~~~~~~~~
Juan Pablo
Lorandi To: [EMAIL PROTECTED]
<rifle@CODEFOUNDR cc:
Y.COM> Subject: Re: ejb method signature-Why
Cant
Sent by: A EJB methods be static-Group Plz.
Contribute
mailing list for
Enterprise
JavaBeans
development
<EJB-INTEREST@JAV
A.SUN.COM>
09/29/02 12:05 AM
Please respond to
Juan Pablo
Lorandi
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".
===========================================================================
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".
