Page History

...

Normally, if two applets have the same codebase and archive parameters, they will be loaded by the same class loader instance. This behavior is required for backward compatibility and is relied on by several real-world applications. The result is that multiple applets on the same web page may access each others' static variables at the Java language level, effectively allowing the multiple applets to be written as though they comprised a single application.

However, applets loaded by different class loader instances are completely isolated and cannot access each others' public static fields. Further, code from any class can access public members of any class that was loaded by any class loader in the delegation chain of the current class's class loader. However, applets loaded by different class loader instances are completely isolated and cannot access each others' public static fields. In the diagram below, for example, code in classes C4 and C5 can freely access public members of class C2, whereas neither class C2} nor class C4 can access public members of class C5.

Image Added

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

...

Fields declared static final are also safe for multithreaded use. (See ; see guideline TSM03-J. Do not publish partially initialized objects. ) On a cautionary note, however, remember that 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 for more information. Further, individual members of the referenced object can also be changed if it the object itself is mutable. (See ; see guideline OBJ01-J. Do not assume that declaring a reference to be final causes the referenced object to be immutable. )

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 of m_functions to be 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.

Noncompliant Code Example (serialVersionUID)

...

The serialization mechanism internally uses the serialVersionUID field internally, so no accessible wrapper methods are requiredunnecessary.

Risk Assessment

Unauthorized modifications of public static variables can result in unexpected behavior and violation of class invariants. Further, because static variables are global across the Java Runtime Environment (JRE)can be visible to code loaded by different class loaders when those class loaders are in the same delegation chain, they can be used as a covert communication channel between different application domains (for example, through code loaded by different class loaders)in some cases.

...