Page History

Callers can trivially access and modify {{public}} {{static}} non-final fields. Neither accesses nor any modifications are automatically checked by a security manager, and newly set values cannot be validated

. Classes loaded by the same class loader can access each others' {{public static}} members, unless appropriate protection is installed. For example, consider Java applets \[[Sun 08|AA. Java References#Sun 08]\]:

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.

In the presence of multiple threads non-final {{public static}} fields can be modified in inconsistent ways. 

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 03|AA. Java References#Gong 03]\]

...