Win a copy of Head First Agile this week in the Agile forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Clarification about static fields  RSS feed

 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just bumbed into an MDB which stores state between invocations in static Hashtables. I knew it's not recommended but decided to check the spec for the details.
Chapter 24.1.2 of EJB 2.0 specification, final release 2, says the following:
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.

Does this mean that we can use "private static final Hashtables" in an MDB and claim spec-compliancy? What I mean is that even though the Hashtable object is final, its state can still be modified as it's not immutable. Now if the Hashtable's state can anyway be modified out-of-sync in each JVM, who cares whether the Hashtables are final or not?
 
Avi Abrami
Ranch Hand
Posts: 1141
1
Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually Lasse,
I believe the problem is not a JVM issue (as noted in the excerpt you provided), but a "ClassLoader" issue. A class can only be loaded once in a given "ClassLoader", and if (for example) an EJB container uses more than one "ClassLoader", then you may get more than one instance of your "private static final HashMap" member. There are several articles describing the "ClassLoader" architecture in J2EE application servers. I know about these:
Understanding J2EE Application Server Class Loading Architectures
Advanced Classloading in J2EE
J2EE Classloading Explained
Hope it helps.
Good Luck,
Avi.
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Avi. I am aware of classloader hierarchies and the problems (trade-offs) caused by this.
However, that's not what I'm asking. What I'm asking is why should we bother to use final if the static field's internal state may be modified at will anyway?
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Using read-only static fields is allowed.

I agree with you Lasse. Does someone has an answer.
 
Vinod John
Ranch Hand
Posts: 162
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Lasse Koskela:
why should we bother to use final if the static field's internal state may be modified at will anyway?

My guess is, People at Sun might have assumed that only immutable objects are normally declared final (static) and wouldn't have consider this special case ???
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!