You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 41 Next »

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.

class variable : A class variable is a static field associated with the containing class.

instance variable : An instance variable is a non-static field that is a part of every instance of the class

sanitization : Sanitization is a term used for validating input and transforming it to a representation that conforms to the input requirements of a complex subsystem. For example, a database may require all invalid characters to be escaped or eliminated prior to their storage. Input sanitization refers to the elimination of unwanted characters from the input by means of removal, replacement, encoding or escaping the characters.

synchronization : "The Java programming language provides multiple mechanisms for communicating between threads. The most basic of these methods is synchronization, which is implemented using monitors. Each object in Java is associated with a monitor, which a thread can lock or unlock. Only one thread at a time may hold a lock on a monitor. Any other threads attempting to lock that monitor are blocked until they can obtain a lock on that monitor." [[JLS 05]].

canonicalization : Reducing the input to its equivalent simplest known form.

conflicting accesses :"Two accesses to (reads of or writes to) the same variable are said to be conflicting if at least one of the accesses is a write." [[JLS 05]].

data race : "When a program contains two conflicting accesses (§17.4.1) that are not ordered by a happens-before relationship, it is said to contain a data race." [[JLS 05]].

happens-before order : "Two actions can be ordered by a happens-before relationship. If one action happens-before another, then the first is visible to and ordered before the second. [...] It should be noted that the presence of a happens-before relationship between two actions does not necessarily imply that they have to take place in that order in an implementation. If the reordering produces results consistent with a legal execution, it is not illegal. [...] More specifically, if two actions share a happens-before relationship, they do not necessarily have to appear to have happened in that order to any code with which they do not share a happens-before relationship. Writes in one thread that are in a data race with reads in another thread may, for example, appear to occur out of order to those reads." [[JLS 05]].

heap memory : "Memory that can be shared between threads is called shared memory or heap memory. All instance fields, static fields and array elements are stored in heap memory.[...] Local variables (§14.4), formal method parameters (§8.4.1) or exception handler parameters are never shared between threads and are unaffected by the memory model." [[JLS 05]].

normalization : Lossy conversion of the data to its simplest known (and anticipated) form. "When implementations keep strings in a normalized form, they can be assured that equivalent strings have a unique binary representation" [[Unicode 08]].

normalization (URI) : Normalization is the process of removing unnecessary "." and ".." segments from the path component of a hierarchical URI. Each "." segment is simply removed. A ".." segment is removed only if it is preceded by a non-".." segment. Normalization has no effect upon opaque URIs [[API 06]].

relativization (URI) : "[Relativization] is the inverse of resolution. For example, relativizing the URI http://java.sun.com/j2se/1.3/docs/guide/index.html against the base URI http://java.sun.com/j2se/1.3 yields the relative URI docs/guide/index.html." [[API 06]].

sequential consistency : "Sequential consistency is a very strong guarantee that is made about visibility and ordering in an execution of a program. Within a sequentially consistent execution, there is a total order over all individual actions (such as reads and writes) which is consistent with the order of the program, and each individual action is atomic and is immediately visible to every thread. [...] If a program is correctly synchronized, then all executions of the program will appear to be sequentially consistent (§17.4.3)." [[JLS 05]]. Sequential consistency implies there will be no compiler optimizations in the statements of the action. Adopting sequential consistency as the memory model can be overly restrictive because under this condition, the compiler is not allowed to make optimizations and reorder code [[JLS 05]].

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.

volatile : "A write to a volatile field (§8.3.1.4) happens-before every subsequent read of that field" [[JLS 05]]. "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]]. Accesses to a volatile variable are [sequentially consistent] which also means that the operations are exempt from compiler optimizations. Declaring a variable volatile ensures that all threads see the most up to date value of the variable, if any thread modifies it. Volatile guarantees atomic reads and writes of primitive values, however, it does not guarantee the atomicity of composite operations such as variable incrementation (read-modify-write sequence).

vulnerability : "A set of conditions that allows an attacker to violate an explicit or implicit security policy" [[Seacord 05]].

  • No labels