...
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 Java Language Specification, §8.4.8.2, "Hiding (by Class Methods)" [JLS 2013] for the formal definition. Contrast with BB. Definitions 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 BB. Definitions shadow the obscured identifier. This can happen if the obscuring identifier is a variable and the obscured identifier is a type, for example. See Java Language Specification, §6.4.2, "Obscuring" [JLS 2013], 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 Java Language Specification, §8.4.8.1, "Overriding (by Instance Methods)" [JLS 2013], for the formal definition. Contrast with BB. Definitionshide.
| Anchor | ||||
|---|---|---|---|---|
|
...
sensitive code: Any code that performs operations that would be forbidden to untrusted code. Also, any code that accesses sensitive data. For example, code whose correct operation requires enhanced privileges is typically considered to be sensitive.
...
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 Java Language Specification, §6.4.1, "Shadowing" [JLS 2013], for more information. Contrast with BB. Definitionsobscure.
| Anchor | ||||
|---|---|---|---|---|
|
...
volatile: "A write to a volatile field happens-before every subsequent read of that field" [JLS 2013, §17.4.5. "Happens-before Order"]. "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, but it does not guarantee the atomicity of composite operations such as variable incrementation (read-modify-write sequence).
...