[concurrency-interest] Minor generics nit in AtomicReferenceArray
takeshi10 at gmail.com
Thu Mar 26 23:56:33 EDT 2009
of the top of my head, i can only think of one example: when you have
a Map<Long, ?> and you fetch with int literal
or more generally, i guess it would be better if it'd accept anything
super V instead of V or Object - that way the compiler would block
calls that would always fail (preserving the type check) and you could
call compareAndSet with any type that can possibly be cast down to the
actual type T
On Thu, Mar 26, 2009 at 11:13 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> On 03/26/2009 09:01 PM, Dhanji R. Prasanna wrote:
>> On Fri, Mar 27, 2009 at 12:33 PM, David M. Lloyd <david.lloyd at redhat.com
>> <mailto:david.lloyd at redhat.com>> wrote:
>> AtomicReferenceArray's type parameter is V. What can I do? I
>> *know* that the expression will only ever be true if "value" is a V,
>> but I have no way to test for it. I can cast the "value" parameter
>> to V and suppress the warning, which will work (the cast is erased),
>> but it's ugly.
>> It's a matter of debate whether ConcurrentMap is too lax or
>> AtomicReferenceArray is too strict, but of those two choices,
>> AtomicReferenceArray is the only one that can be fixed in a
>> backwards-compatible fashion.
>> I don't know. I think the balance between an erased cast in this
>> (admittedly) rare case and weakening the type signature of
>> AtomicReferenceArray tips in the former's direction, don't you?
>> At the very least for the sake of clarity and tools...
> Only if you think that weakening the type signature is inherently a bad
> thing. I don't. I see no concrete evidence that using a strong type for
> this parameter is a good thing (it has certainly never helped me). On the
> other hand, my personal experience shows that it can be a hinderance.
> - DML
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
Marcelo Takeshi Fukushima
More information about the Concurrency-interest