...
exploit [Seacord 2005]
A piece of software or a technique that takes advantage of a security vulnerability to violate an explicit or implicit Rule BB: Glossary security policy.
| Anchor | ||||
|---|---|---|---|---|
|
fail fast [Gray 1985]
software that either functions correctly or detects the fault, signals failure, and stops operating.
...
hide One class field hides a field in a superclass if they have the same identifier. The hidden field is not accessible from the class. Likewise, a class method hides a method in a superclass if they have the same identifier but incompatible signatures. The hidden method is not accessible from the class. See [JLS 2005] §8.4.8.2 for the formal definition. Contrast with Rule BB: Glossary override.
| Anchor | ||||
|---|---|---|---|---|
|
...
obscure One scoped identifier obscures another identifier in a containing scope if the two identifiers are the same, but the obscuring identifier does not Rule BB: Glossary shadow the obscured identifier. This can happen when the obscuring identifier is a variable while the obscured identifier is a type, for example. See [JLS 2005] §6.3.2 for more information.
...
override One class method overrides a method in a superclass if they have compatible signatures. The overridden method is still accessible from the class via the super keyword. See [JLS 2005] §8.4.8.1 for the formal definition. Contrast with Rule BB: Glossary hide.
| Anchor | ||||
|---|---|---|---|---|
|
...
shadow One scoped identifier shadows another identifier in a containing scope if the two identifiers are the same and they both reference variables. They may also both reference methods or types. The shadowed identifier is not accessible in the scope of the shadowing identifier. See [JLS 2005] §6.3.1 for more information. Contrast with Rule BB: Glossary obscure.
| Anchor | ||||
|---|---|---|---|---|
|
...
volatile "A write to a volatile field (§8.3.1.4) happens-before every subsequent read of that field" [JLS 2005]. "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]. 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).
...