[concurrency-interest] New field accessor APIs

John Platts john_platts at hotmail.com
Fri Nov 26 14:34:49 EST 2010

Here are reasons why new field accessor APIs are needed:
- To improve portability, correctness, and thread safety of code using the improved field accessor APIs. Writes to reference fields through methods in sun.misc.Unsafe are not type safe. The sun.misc.Unsafe class is not part of the Java SE specification and is not guaranteed to be available in a Java SE implementation.
- To allow volatile reads, volatile writes, lazy volatile writes, and atomic operations to be performed on non-volatile fields. These operations are often useful on non-volatile fields as they enable thread-safe initialization of non-volatile fields, while allowing subsequent accesses to be optimized. Supporting volatile writes of non-volatile fields also allows inversion of control and dependency control containers to ensure that non-volatile fields are properly initialized and written to in a thread-safe manner.
- To allow field updaters to be created through lookup classes (similar to the java.dyn.MethodHandles.Lookup class in Java SE 7 and later). This is useful in dynamic programming languages, as it provides capabilities that are not yet available in JSR 292. MethodHandle objects can be used to read from or write to a field. However, field updaters can perform atomic operations, write to non-volatile fields using volatile writes, perform lazy volatile writes, and read to non-volatile fields using volatile reads, things that MethodHandles cannot do directly.
- To facilitate the implementation of JVM programming languages whose field access semantics differ from the Java Programming Language.

The new field accessor APIs provide the following guarantees:
- Static final fields are never written to through the new field accessor APIs
- Writes to final instance fields through the new field accessors are not enabled by default
- Security checks and immutability of final fields are enforced by default
- Callers must have permission to disable security checks and final field immutability checks
- Volatile and final fields are never written to through a non-volatile write
- Reads to volatile fields through the new field accessor API's are normal volatile reads by default


More information about the Concurrency-interest mailing list