atomicity : When applied to an operation on primitive data, indicates that other threads that might access the data might see the data as it exists before the operation occurs or after the operation has completed, but may never see an intermediate value of the data.
trusted code : Code that is loaded by the primordial class loader, irrespective of whether it constitutes the Java API or not. In this text, this meaning is extended to include code that is obtained from a known entity and given permissions that untrusted code lacks. By this definition, untrusted and trusted code can coexist in the namespace of a single class loader (not necessarily the primordial class loader). In such cases, the security policy must make this distinction clear by assigning appropriate privileges to trusted code, while denying the same from untrusted code.
untrusted code : Code of unknown origin that can potentially cause some harm when executed. Untrusted code may not always be malicious but this is usually hard to determine automatically. Consequently, untrusted code should be run in a sandboxed environment.
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="b09f5061-c7fe-4336-b349-7398e2fdf0b3"><ac:parameter ac:name=""> volatile</ac:parameter></ac:structured-macro>
volatile : Declaring a variable volatile ensures that all threads see a consistent value of the variable. Volatile guarantees atomic reads and writes of values, however, it does not guarantee the atomicity of composite operations such as variable incrementation (read-modify-write sequence). "Operations on the master copies of volatile variables on behalf of a thread are performed by the main memory in exactly the order that the thread requested." [[JVMSpec 99]].