Page History

*alien method* : "From the perspective of a class C, an alien method is one whose behavior is not fully specified by C. This includes methods in other classes as well as overrideable methods (neither private nor final) in C itself." \[[Goetz 2006|AA. Java References#GoetzBibliography#Goetz 06]\].

*condition predicate* : A condition predicate is an expression constructed from the state variables of a class that must be true for a thread to continue execution. The thread pauses execution, via {{Object.wait()}}, {{Thread.sleep()}}, or some other mechanism, and is resumed later, presumably when the requirement is true and when it is notified \[[Goetz 2006|AA. Java References#GoetzBibliography#Goetz 06]\]. 

*conflicting accesses* : Two accesses to (reads of or writes to) the same variable provided that at least one of the accesses is a write. \[[JLS 2005|AA. Java References#JLSBibliography#JLS 05]\].

*data race* : Conflicting accesses of the same variable that are not ordered by a happens-before relationship" \[[JLS 2005|AA. Java References#JLSBibliography#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 2005|AA. Java References#JLSBibliography#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 2005|AA. JavaBibliography#JLS References#JLS 05]\]. 

\[12\] It is technically possible to have an immutable object without all fields being {{final}}. {{String}} is such a class but this relies on delicate reasoning about benign data races that requires a deep understanding of the Java Memory Model. (For the curious: {{String}} lazily computes the hash code the first time {{hashCode}} is called and caches it in a nonfinal field, but this works only because that field can take on only one nondefault value that is the same every time it is computed because it is derived deterministically from immutable state." \[[Goetz 2006|AA. JavaBibliography#Goetz References#Goetz 06]\].

*initialization safety* : "An object is considered to be completely initialized when its constructor finishes. A thread that can only see a reference to an object after that object has been completely initialized is guaranteed to see the correctly initialized values for that object's final fields." \[[JLS 2005|AA. Java References#JLSBibliography#JLS 05]\].

*interruption policy:*  "An interruption policy determines how a thread interprets an interruption request - what it does (if anything) when one is detected, what units of work are considered atomic with respect to interruption, and how quickly it reacts to interruption." \[[Goetz 2006|AA. Java References#GoetzBibliography#Goetz 06]\].

*memory model*: "The rules that determine how memory accesses are ordered and when they are guaranteed to be visible are known as the memory model of the Java programming language" \[[JPL 2006|AA. JavaBibliography#JPL References#JPL 06]\]. "A memory model describes, given a program and an execution trace of that program, whether the execution trace is a legal execution of the program." \[[JLS 2005|AA. JavaBibliography#JLS References#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 2008|AA. Java References#UnicodeBibliography#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 2006|AA. Java References#APIBibliography#API 06]\].

*obsolete reference* : "An obsolete reference is simply a reference
that will never be dereferenced again." \[[Bloch 2008|AA. Java References#BlochBibliography#Bloch 08]\].

*open call* : "An alien method invoked outside of a synchronized region is known as an open call \[Lea00 2.4.1.3\]". \[[Bloch 2008|AA. Java References#BlochBibliography#Bloch 08]\] and \[[Lea 2000|AA. Java References#LeaBibliography#Lea 00]\].

*partial order* :  An order defined for some, but not necessarily all, pairs of items. For instance, the sets \{a, b\} and \{a, c, d\} are subsets of \{a, b, c, d\}, but neither is a subset of the other. So "subset of" is a partial order on sets. \[[Black 2004|AA. Java References#BlackBibliography#Black 04]\]

*publishing objects* : "Publishing an object means making it available to code outside of its current scope, such as by storing a reference to it where other code can find it, returning it from a nonprivate method, or passing it to a method in another class." \[[Goetz 2006|AA. Java References#GoetzBibliography#Goetz 06]\].

*race condition:* "General races cause nondeterministic execution and are failures in programs intended to be deterministic." \[[Netzer 1992|AA. Java References#NetzerBibliography#Netzer 92]\]. "A race condition occurs when the correctness of a computation depends on the relative timing or interleaving of multiple threads by the runtime" \[[Goetz 2006|AA. Java References#GoetzBibliography#Goetz 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 2006|AA. JavaBibliography#API References#API 06]\].

*safety* : Its main goal is to ensure that all objects maintain consistent states in a multi-threaded environment \[[Lea 2000|AA. JavaBibliography#Lea References#Lea 00]\].

*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 2005|AA. Java References#JLSBibliography#JLS 05]\]. Sequential consistency implies there will be no compiler optimizations in the statements of the action. Adopting sequential consistency as the memory model and disallowing other primitives can be overly restrictive because under this condition, the compiler is not allowed to make optimizations and reorder code \[[JLS 2005|AA. Java References#JLSBibliography#JLS 05]\].

*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 2005|AA. JavaBibliography#JLS References#JLS 05]\].

*thread-safe* : An object is thread-safe, if it can be shared by multiple threads without the possibility of any data races. "A thread-safe object performs synchronization internally, so multiple threads can freely access it through its public interface without further synchronization." \[[Goetz 2006|AA. JavaBibliography#Goetz References#Goetz 06]\]. Immutable classes are thread safe by definition. Mutable classes may also be thread-safe if they are properly synchronized. 

*total order* An order defined for all pairs of items of a set. For instance, <= (less than or equal to) is a total order on integers, that is, for any two integers, one of them is less than or equal to the other. \[[Black 2006|AA. Java References#BlackBibliography#Black 06]\]

*volatile* : "A write to a volatile field (§8.3.1.4) happens-before every subsequent read of that field" \[[JLS 2005|AA. Java References#JLSBibliography#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 1999|AA. Java References#JVMSpecBibliography#JVMSpec 99]\]. Accesses to a {{volatile}} variable are [sequentially consistent|BB. Definitions#sequential consistency] 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 2005|AA. Java References#SeacordBibliography#Seacord 05]\].