...
In the presence of multiple threads, non-final public static fields can be modified in inconsistent ways. (see See guideline "TSM01-J. Do not let the (this) reference escape during object construction" for an example.)
| Wiki Markup |
|---|
Improper use of {{public static}} fields can also result in type safety issues. For example, untrusted code can supply an unexpected subtype when the variable is defined to be of a more general type, such as {{java.lang.Object}} \[[Gong 2003|AA. Bibliography#Gong 03]\]. |
...
Fields declared static final are also safe for multithreaded use. (see See guideline "TSM03-J. Do not publish partially initialized objects.") However, remember that simply changing the modifier to final may might not prevent attackers from indirectly retrieving an incorrect value from the static final variable before its initialization. (see See guideline "DCL12-J. Prevent class initialization cycles" for more information.) Furthermore, individual members of the referenced object can also be changed if the object itself is mutable. (see See guideline "OBJ02-J. Never conflate immutability of a reference with that of the referenced object.")
It is also permissible to use a wrapper method to retrieve the value of m_functions. This has encapsulation advantages as because it permits m_functions to be declared private. See guideline "OBJ01-J. Declare data members as private and provide accessible wrapper methods" for more information.
Noncompliant Code Example (serialVersionUID)
...
| Wiki Markup |
|---|
\[[FT 2008|AA. Bibliography#FT 08]\] Function Table Class Function Table
\[[Gong 2003|AA. Bibliography#Gong 03]\] 9.3 Static Fields
\[[Nisewanger 2007|AA. Bibliography#Nisewanger 07]\] Antipattern 5, Misusing Public Static Variables
\[[Sterbenz 2006|AA. Bibliography#Sterbenz 06]\] Antipattern 5, Misusing Public Static Variables |
...