On 4/21/2010 8:35 PM, David Holmes wrote:
Jeff I'm a little confused about the reasoning here. I was surprised to
discover that the atomic updaters allow you to perform accesses that
direct bytecode and reflection do not (perhaps I knew this when we put
them together but have since forgotten). So
Jeff,
I totally agree with your analysis.
I'd like to see better javadoc for java.util.concurrent.atomic
in general. I'm not sure I'm the best person to come
up with the kind of security-related javadoc we want to see here.
The key idea is that, like an instance of Unsafe,
an updater is a token
On 4/16/2010 5:50 AM, David Holmes wrote:
Hi Doug,
approval as I'm not a subscriber.>
Doug Lea said the following on 04/16/10 21:43:
On 04/15/10 18:34, Martin Buchholz wrote:
People are using Atomic field updaters to update fields in classes
in other classloaders.
I think the policy on
On 4/19/2010 11:23 AM, Martin Buchholz wrote:
Jeff, please review.
Yes, will do. I was caught up with other things last week. I will
try to go through and catch up with this discussion later today.
Jeff
Jeff I'm a little confused about the reasoning here. I was surprised to
discover that the atomic updaters allow you to perform accesses that
direct bytecode and reflection do not (perhaps I knew this when we put
them together but have since forgotten). So contrary to my expectation
that the rea
Hi David,
I think you've done a good job of convincing me!
The key idea is that updaters should mimic the access permissions
of regular field updates by callers. Since those are not affected by
what's further up the stack, neither should the field updaters.
So I'm promoting myself from "messeng
On 04/15/10 18:34, Martin Buchholz wrote:
People are using Atomic field updaters to update fields in classes in other
classloaders.
I think the policy on this awaits interpretation by Jeff
or other members of security team. FWIW, my take is that
if users know that they may cross class loaders
Hi Doug,
approval as I'm not a subscriber.>
Doug Lea said the following on 04/16/10 21:43:
On 04/15/10 18:34, Martin Buchholz wrote:
People are using Atomic field updaters to update fields in classes in
other classloaders.
I think the policy on this awaits interpretation by Jeff
or other
Martin Buchholz said the following on 04/16/10 16:58:
On Thu, Apr 15, 2010 at 19:04, David Holmes wrote:
Aside: you forgot to call pass().
Not strictly necessary, since the test fails if and only if it throws.
Ok but it looks odd to print "pass 0 fail 0" ;-)
Now, they
could work around th
On Thu, Apr 15, 2010 at 19:04, David Holmes wrote:
> Martin Buchholz said the following on 04/16/10 11:38:
>>
>> On Thu, Apr 15, 2010 at 17:49, David Holmes
>> wrote:
>>>
>>> If this proceeds I think you need to include AtomicReferenceFieldUpdater
>>> in
>>> this as well.
>>
>> Agreed.
>>
>> I ma
Martin Buchholz said the following on 04/16/10 11:38:
On Thu, Apr 15, 2010 at 17:49, David Holmes wrote:
If this proceeds I think you need to include AtomicReferenceFieldUpdater in
this as well.
Agreed.
I may have created some confusion because the test in my webrev
did not actually demonstr
Hi Martin,
If this proceeds I think you need to include AtomicReferenceFieldUpdater
in this as well.
But this is not a clear cut issue (security never is!).
If I understand the test program correctly the problem arises when the
target object's class was loaded by a different class-loader to
On Thu, Apr 15, 2010 at 17:49, David Holmes wrote:
> Hi Martin,
>
> If this proceeds I think you need to include AtomicReferenceFieldUpdater in
> this as well.
Agreed.
I may have created some confusion because the test in my webrev
did not actually demonstrate the problem.
I have since fixed tha
Hi java.util.concurrent security team,
People are using Atomic field updaters to update fields in classes in
other classloaders.
Toby writes:
We received a bug report for App Engine that AtomicLongFieldUpdater
(and its sibling) were failing with RuntimePermission
accessDeclaredMembers. Looking a
14 matches
Mail list logo
