Page History

...

In the presence of multiple threads, non-final public static fields can be modified in inconsistent ways. (for For example, see guideline TSM01-J. Do not let the (this) reference escape during object construction.) .

Improper use of {{public static}} fields can also result in type safety issues. For example, untrusted code may supply an unexpected subtype when the variable is defined to be of a more general type such as {{java.lang.Object}}. \[[Gong 2003|AA. Java References#Gong 03]\].

Noncompliant Code Example

...

Fields declared static final are also safe for multithreaded use. (See guideline TSM03-J. Do not publish partially initialized objects.) . On a cautionary note, however, simply changing the modifier to final may not prevent attackers from indirectly retrieving an incorrect value from the static final variable before its initialization. (see See guideline MSC07-J. Eliminate class initialization cycles.) . Individual members of the referenced object can also be changed if it is mutable. (see See guideline OBJ01-J. Be aware that a final reference may not always refer to immutable data.) .

It is also permissible to use a wrapper method to retrieve the value of m_functions. This has encapsulation advantages as it restricts its accessibility to private. (see See guideline OBJ00-J. Declare data members as private and provide accessible wrapper methods.) . However, it is unnecessary when m_functions needs to be treated like a world-accessible constant.

...

Unauthorized modifications of public static variables can result in unexpected behavior and violation of class invariants.

...