static field in bean class

[Rashmi Tambe]

I know, this issue must have been discussed a thousand times...but i just noticed a strange behavior that confused me!
The para 24.1.2 (Programming restrictions )in ejb Spec says-
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.
In a stateless session bean, I declared one instance variable as static and modified its value in
ejbCreate(). I was expecting that ejbc would give error for using non-final static field in a bean class.
but...it didn't! The bean got deployed properly too. How? I think ejbc shpuld have complained for such
a case that is against ejb spec.....

[Vijay Pawar]

Hello Rashmi,
Consider a stateless session bean. A container would have created 100 instances of it. Now a static variable would be common to all the 100 instances hence it is advisible to have it read only be making it final.
Although a bean instance could modify its value and that modified value could be read by another bean. This variable does not make any sense. So it would be a flaw in the application to use a non-final static variable.
Possible at deploy time the deploy tool does not check for this condition !
I think the same should be tested with other servers like Websphere/Weblogic.
Thanks
Jughead

[Rashmi Tambe]

I am using Weblogic server 7.0.1. My problem is not the usage of static field. I am aware of the reasons why u should not use non-final static field. My concern is....If the EJB spec says that some thing should not be done by enterprise bean, then either ejbc or the container should restrict this
SO if the ejbc passes through and the bean get deployed properly and if read/write of a static field is working fine...then it is a very much confusing situation for a developer who has read the specs. If for new developers, who are not aware of this condition, might actually use static fields without knowing its hazards.... which can turn out to be problematic.
So my concern is...the authority of ejb specs remains doubtful, if the things that are not allowed according to specs are actually allowed and working in a practical situation which is definitely not desirable.

[Vijay Pawar]

Let us again concentrate on the specs,
It says:
Therefore, it is recommended that all static fields in the enterprise bean class be declared as final.
It is not a must criteria ? It is a recommendation and that too, for the Bean Provider and not for the Container Provider.
I think this should solve your query.

[Vishwa Kumba]

Most of the programming restrictions do not seem to have an explanation in the specs. We believe violating the recommendations could lead to portability issues. Most of the times, the clients stick to one App Server. So not sure how portability could be the primary issue.
By the way, I found this in the EJB1.1 specs:

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

Not sure what the side-effects of this would be in EJB2.0 with local interfaces if beans run in multiple JVMs :roll:
[ March 10, 2004: Message edited by: Vish Kumar ]

[Reid M. Pinchback]

It is important not to use static fields for anything other than constants (i.e. static final ...).
If you use static fields, then many beans could be writing to those fields. You now now thread synchronization problems to worry about. Also, you have no guarantees about how any given container will use class loaders to manage different applications and different homes within those applications. If you use mutable static fields, you could be sharing the data more broadly than you intended. You are supposed to be able to do multiple deployments of bean code using different descriptors and JNDI bindings, but mutable static fields could very well break that.

[Vishwa Kumba]

Originally posted by Reid M. Pinchback:
If you use static fields, then many beans could be writing to those fields. You now now thread synchronization problems to worry about.

Cheers Reid!.....
That's good point!