Page History

Client code can trivially access {{public}} {{static}} non-final fields. Neither reads nor writes are checked by a security manager; further, new values cannot be validated programmatically before they are stored in the field. Classes loaded by the same class loaders can access each others' {{public static}} members; further, code from any class can access {{public}} members of any classes loaded by class loaders in the delegation chain of the current class's class loader. For example, consider Java applets \[[Sun 2008|AA. Bibliography#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.

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.

...