[concurrency-interest] The Atomic*FieldUpdater situation
dl at cs.oswego.edu
Mon Jul 23 06:44:28 EDT 2012
On 07/22/12 16:47, David M. Lloyd wrote:
>>> I still don't get why this needs to operate any differently than
>>> reflection. With reflection I can do the same thing in Backdoor. I just
>>> make a call to setAccessible, and a security check is done with a
>>> security manager. Why can't the updaters do the same?
This is a good point. Among the ideas for internal overhaul
would be to build special versions for fields that have been
I am holding out some hope that between this and use of
upcoming indy extensions, we might be able to provide
much better versions. (Although ultimately, the only
way to do this completely seamlessly would be to add
bytecodes and front-end compiler support.)
Until then, I'm not especially tempted to create band-aid version.
The mechanics available are very fragile. When introducing and
revising these, we've had many exchanges with Java security folks
who are insistent about the use of particular constructions.
They do tend to be very conservative, but that's mainly
because this is hard to get exactly right, especially in
the presence of erased generics.
However, in the mean time, it would be completely possible for
you to create your own AccessibleAtomicXFieldUpdater classes
(so long as you have access to Unsafe) and use them.
More information about the Concurrency-interest