You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Prashanth K S <pr...@gmail.com> on 2010/11/30 18:54:44 UTC
Re: [jira] Updated: (HARMONY-6681) AbstractCollection.toArray() and
AbstractCollection.toArray(T[]) are broken for concurrently modified
collections like ConcurrentHashMap.keySet()
JIRA 6678 attempts to address the same. A patch has been attached to the
JIRA and is yet to be committed. Kindly test the behavior after the fix has
been committed.
--
Regards
Prashanth
On Tue, Nov 30, 2010 at 10:18 PM, Uwe Schindler (JIRA) <ji...@apache.org>wrote:
>
> [
> https://issues.apache.org/jira/browse/HARMONY-6681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>
> Uwe Schindler updated HARMONY-6681:
> -----------------------------------
>
> Description:
> If you call ConcurrentHashMap.keySet().toArray() [as done in trunks
> Lucene's RAMDirectory#fileMap] and another thread modifies the collecton,
> you get NoSuchElementExceptions or AIOOBEs. The reason is that
> AbstractCollection.toArray methods allocate the array using the current size
> of the collection and then either iterate on the values (which is oficially
> supported by ConcurrentHashMap, its iterator is safe for concurrent
> modification!) and set them on the target without checking bounds. On the
> other hand if there are too few entries in the collection, the array is
> nulled at the end. The bad thing is that the toArray() and toArray(T[])
> methods behave differently, so depending on the modification they throw
> different exceptions (one impl simply drops entries that dont fit into the
> array).
>
> Since Java SE 6, its officially documented, how toArray must behave: [
> http://download.oracle.com/javase/6/docs/api/java/util/AbstractCollection.html#toArray(T[])<http://download.oracle.com/javase/6/docs/api/java/util/AbstractCollection.html#toArray%28T[]%29>];
> This is violated by harmony and even the fix in HARMONY-6236 does not
> respect it, leading to such bugs.
>
> Java SE 5 does not document that, but ConcurrentHashMap.keySet(), values()
> and entrySet() have own implementations of toArray() (which can be found out
> by reflection), the root AbstractCollection.toArray() is not behaving fine
> there.
>
> For harmony the fix would be to correct this issue "correctly" by changing
> the base AbstractCollection implementation (I would recommend that).
>
> This is also the root cause for HARMONY-6236 and similar issues, the fix
> there is invalid, but I cannot reopen the issue.
>
> was:
> If you call ConcurrentHashMap.keySet().toArray() [as done in trunks
> Lucene's RAMDirectory#fileMap] and another thread modifies the collecton,
> you get NoSuchElementExceptions or AIOOBEs. The reason is that
> AbstractCollection.toArray methods allocate the array using the current size
> of the collection and then either iterate on the values (which is oficially
> supported by ConcurrentHashMap, its iterator is safe for concurrent
> modification!) and set them on the target without checking bounds. On the
> other hand if there are too few entries in the collection, the array is
> nulled at the end. The bad thing is that the toArray() and toArray(T[])
> methods behave differently, so depending on the modification they throw
> different exceptions (one impl simply drops entries that dont fit into the
> array).
>
> Since Java SE 6, its officially documented, how toArray must behave: [
> http://download.oracle.com/javase/6/docs/api/java/util/AbstractCollection.html#toArray(T[])<http://download.oracle.com/javase/6/docs/api/java/util/AbstractCollection.html#toArray%28T[]%29>];
> This is violated by harmony and even the fix in HARMONY-6419 does not
> respect it, leading to such bugs.
>
> Java SE 5 does not document that, but ConcurrentHashMap.keySet(), values()
> and entrySet() have own implementations of toArray() (which can be found out
> by reflection), the root AbstractCollection.toArray() is not behaving fine
> there.
>
> For harmony the fix would be to correct this issue "correctly" by changing
> the base AbstractCollection implementation (I would recommend that).
>
> This is also the root cause for HARMONY-6419 and similar issues, the fix
> there is invalid, but I cannot reopen the issue.
>
>
> > AbstractCollection.toArray() and AbstractCollection.toArray(T[]) are
> broken for concurrently modified collections like ConcurrentHashMap.keySet()
> >
> -------------------------------------------------------------------------------------------------------------------------------------------------
> >
> > Key: HARMONY-6681
> > URL: https://issues.apache.org/jira/browse/HARMONY-6681
> > Project: Harmony
> > Issue Type: Bug
> > Components: Classlib
> > Affects Versions: 6.0M4, 5.0M16
> > Reporter: Uwe Schindler
> >
> > If you call ConcurrentHashMap.keySet().toArray() [as done in trunks
> Lucene's RAMDirectory#fileMap] and another thread modifies the collecton,
> you get NoSuchElementExceptions or AIOOBEs. The reason is that
> AbstractCollection.toArray methods allocate the array using the current size
> of the collection and then either iterate on the values (which is oficially
> supported by ConcurrentHashMap, its iterator is safe for concurrent
> modification!) and set them on the target without checking bounds. On the
> other hand if there are too few entries in the collection, the array is
> nulled at the end. The bad thing is that the toArray() and toArray(T[])
> methods behave differently, so depending on the modification they throw
> different exceptions (one impl simply drops entries that dont fit into the
> array).
> > Since Java SE 6, its officially documented, how toArray must behave: [
> http://download.oracle.com/javase/6/docs/api/java/util/AbstractCollection.html#toArray(T[])<http://download.oracle.com/javase/6/docs/api/java/util/AbstractCollection.html#toArray%28T[]%29>];
> This is violated by harmony and even the fix in HARMONY-6236 does not
> respect it, leading to such bugs.
> > Java SE 5 does not document that, but ConcurrentHashMap.keySet(),
> values() and entrySet() have own implementations of toArray() (which can be
> found out by reflection), the root AbstractCollection.toArray() is not
> behaving fine there.
> > For harmony the fix would be to correct this issue "correctly" by
> changing the base AbstractCollection implementation (I would recommend
> that).
> > This is also the root cause for HARMONY-6236 and similar issues, the fix
> there is invalid, but I cannot reopen the issue.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>