Page History

...

Improper use of public static fields can also result in type-safety issues. For example, untrusted code can supply an unexpected subtype with malicious methods when the variable is defined to be of a more general type, such as {{java.lang.Object}} \[[Gong 2003|AA. Bibliography#Gong 03]\]. As a result, classes must not contain nonfinal public static fields.

...

Replacing the function table gives the attacker access to XPathContext, which is used to set the reference node for evaluating XPath expressions. Manipulating XPathContext can cause XML fields to be modified in inconsistent ways, resulting in unexpected behavior. Also, because static variables are global across the Java Runtime Environment (JRE), they can be used as a covert communication channel between different application domains (for example, through code loaded by different class loaders).

Note that this This vulnerability was repaired in JDK v1.4.2_05.

...

public static final FuncLoader m_functions;
// Initialize m_functions in a constructor

Fields declared static and final are also safe for multithreaded use. (See rule [TSM03-J. Do not publish partially initialized objects for more information.) However, remember that simply changing the modifier to final might not prevent attackers from indirectly retrieving an incorrect value from the static final variable before its initialization. (See rule DCL00-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.

...

Noncompliant Code Example (serialVersionUID)

This noncompliant code example uses a public static nonfinal serialVersionUID field in a class designed for serialization.

...

This compliant solution declares the serialVersionUID field final and limits its accessibility to private.

class DataSerializer implements Serializable {
  private static final long serialVersionUID = 1973473122623778747L;
}

...

...