You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Spark Shen <sm...@gmail.com> on 2006/08/19 10:48:11 UTC
[classlib][luni] Suspicious behavior of java.util.EnumSet
Hi All:
The following behavior of RI java.util.EnumSet seems odd. Do you have
any opinion on whether it is a bug of RI?
import java.util.EnumSet;
import java.util.Iterator;
public class Test {
static enum EnumFoo {
a, b,
}
public static void main(String[] args){
EnumSet<EnumFoo> set = EnumSet.noneOf(EnumFoo.class);
set.add(EnumFoo.a);
Iterator<EnumFoo> iterator = set.iterator();
iterator.next();
set.remove(EnumFoo.a);
iterator.remove(); (1)
// The output value is true
System.out.println(set.contains(EnumFoo.a));
// The output value is 64
System.out.println(set.size());
}
}
IMHO, when (1) is executed, an IllegalStateException should be thrown
out, since the element EnumFoo.a does not exist at the moment.
Any thoughts?
Best regards
--
Spark Shen
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][luni] Suspicious behavior of java.util.EnumSet
Posted by Paulex Yang <pa...@gmail.com>.
Spark Shen wrote:
>
> But, do you agree to following RI on this strange behavior?
> Personally, I think throw an IllegalStateException here is more
> appropriate.
The spec for Iterator.remove() says:
"Throws ||IllegalStateException - if the next method has not yet been
called, or the remove method has already been called after the last call
to the next method."
So IMHO, it doesn't follow spec to throw IllegalStateException here, if
we think RI has bug here, the more careful solution is do nothing and
return.
>
> Best regards
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][luni] Suspicious behavior of java.util.EnumSet
Posted by Spark Shen <sm...@gmail.com>.
Jimmy, Jing Lv 写道:
> Spark Shen wrote:
>> Hi All:
>> The following behavior of RI java.util.EnumSet seems odd. Do you have
>> any opinion on whether it is a bug of RI?
>>
>> import java.util.EnumSet;
>> import java.util.Iterator;
>> public class Test {
>> static enum EnumFoo {
>> a, b,
>> }
>>
>> public static void main(String[] args){
>> EnumSet<EnumFoo> set = EnumSet.noneOf(EnumFoo.class);
>> set.add(EnumFoo.a);
>> Iterator<EnumFoo> iterator = set.iterator();
>> iterator.next();
>> set.remove(EnumFoo.a);
>> iterator.remove(); (1)
>> // The output value is true
>> System.out.println(set.contains(EnumFoo.a));
>> // The output value is 64
>> System.out.println(set.size());
>> }
>> }
>> IMHO, when (1) is executed, an IllegalStateException should be thrown
>> out, since the element EnumFoo.a does not exist at the moment.
>> Any thoughts?
>>
>> Best regards
>>
>
> Not very familiar with Enumset, but I think it is strange behavior
> caused by iterator
Agree.
>
> This test can pass on RI
> void test{
> EnumSet<EnumFoo> set = EnumSet.noneOf(EnumFoo.class);
> set.add(EnumFoo.a);
> assertTrue(set.size() == 1);
> assertTrue(set.remove(EnumFoo.a));
> assertTrue(set.size() == 0);
> assertFalse(set.remove(EnumFoo.a));
> assertFalse(set.contains(EnumFoo.a));
> }
>
> Without Iterator influence, the EnumSet behave well. I think better to
> focus on how iterator works there.
But, do you agree to following RI on this strange behavior? Personally,
I think throw an IllegalStateException here is more appropriate.
Best regards
--
Spark Shen
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][luni] Suspicious behavior of java.util.EnumSet
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
Spark Shen wrote:
> Hi All:
> The following behavior of RI java.util.EnumSet seems odd. Do you have
> any opinion on whether it is a bug of RI?
>
> import java.util.EnumSet;
> import java.util.Iterator;
> public class Test {
> static enum EnumFoo {
> a, b,
> }
>
> public static void main(String[] args){
> EnumSet<EnumFoo> set = EnumSet.noneOf(EnumFoo.class);
> set.add(EnumFoo.a);
> Iterator<EnumFoo> iterator = set.iterator();
> iterator.next();
> set.remove(EnumFoo.a);
> iterator.remove(); (1)
> // The output value is true
> System.out.println(set.contains(EnumFoo.a));
> // The output value is 64
> System.out.println(set.size());
> }
> }
> IMHO, when (1) is executed, an IllegalStateException should be thrown
> out, since the element EnumFoo.a does not exist at the moment.
> Any thoughts?
>
> Best regards
>
Not very familiar with Enumset, but I think it is strange behavior
caused by iterator
This test can pass on RI
void test{
EnumSet<EnumFoo> set = EnumSet.noneOf(EnumFoo.class);
set.add(EnumFoo.a);
assertTrue(set.size() == 1);
assertTrue(set.remove(EnumFoo.a));
assertTrue(set.size() == 0);
assertFalse(set.remove(EnumFoo.a));
assertFalse(set.contains(EnumFoo.a));
}
Without Iterator influence, the EnumSet behave well. I think better to
focus on how iterator works there.
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][luni] Suspicious behavior of java.util.EnumSet
Posted by Leo Li <li...@gmail.com>.
In my opinion, it is just RI' s implementation and it is up to you as a
developer to make the choice.:)
On 8/21/06, Spark Shen <sm...@gmail.com> wrote:
>
> Leo Li 写道:
> > If so, we cannot regard it as RI's bug. And I believe the size of 64
> > and the
> > existence of the deleted element depends on RI's algorithm especially it
> > does not provide concurrent assurance. Maybe it is due to performance
> > concerns, I am not sure.
> > The curious thing is whether we should behave as RI since it says "it
> > may or
> > may not show the effects of any modifications to the set that occur
> while
> > the iteration is in progress".
> >
> >
> So, what is your opinion? Should we follow RI on this behavior?
>
> Best regards
> > On 8/21/06, Spark Shen <sm...@gmail.com> wrote:
> >>
> >> Leo Li 写道:
> >> > Hi, Spark:
> >> > Yes, I think it is RI's bug.
> >> > But It should throw ConcurrentModificationException as spec says:
> >> > 1. This exception may be thrown by methods that have detected
> >> > concurrent modification of an object when such modification is not
> >> > permissible.
> >> > 2. Note that this exception does not always indicate that an object
> >> has
> >> > been concurrently modified by a *different* thread. If a single
> thread
> >> > issues a sequence of method invocations that violates the contract
> >> of an
> >> > object, the object may throw this exception. For example, if a thread
> >> > modifies a collection directly while it is iterating over the
> >> collection
> >> > with a fail-fast iterator, the iterator will throw this exception.
> >> >
> >> > The iterator 's remove() action relies on the result of previous
> >> > next(), but is interrupted by the set.remove() method. I think it
> >> is the
> >> > case.
> >> >
> >> > Besides, If the same thing is applied to Hashset:
> >> > public static void main(String[] args) {
> >> > HashSet set = new HashSet();
> >> > Object o = new Object();
> >> > set.add(o);
> >> > Iterator iter = set.iterator();
> >> > iter.next();
> >> > set.remove(o);
> >> > iter.remove();
> >> > }
> >> > It will throw ConcurrentModificationException as expected.:)
> >> >
> >> >
> >> There is a paragraph from spec clearly states that
> >> ConcurrentModificationException will never be thrown out from the
> >> iterator returned
> >> by EnumSet. Cited below:
> >> "The returned iterator is /weakly consistent/: it will never throw
> >> |ConcurrentModificationException|
> >> <ci...@gmail.com>
> >> and it may or may not show the effects of any modifications to the set
> >> that occur while the iteration is in progress."
> >>
> >> Best regards
> >> > On 8/19/06, Spark Shen <sm...@gmail.com> wrote:
> >> >>
> >> >> Hi All:
> >> >> The following behavior of RI java.util.EnumSet seems odd. Do you
> have
> >> >> any opinion on whether it is a bug of RI?
> >> >>
> >> >> import java.util.EnumSet;
> >> >> import java.util.Iterator;
> >> >> public class Test {
> >> >> static enum EnumFoo {
> >> >> a, b,
> >> >> }
> >> >>
> >> >> public static void main(String[] args){
> >> >> EnumSet<EnumFoo> set = EnumSet.noneOf(EnumFoo.class);
> >> >> set.add(EnumFoo.a);
> >> >> Iterator<EnumFoo> iterator = set.iterator();
> >> >> iterator.next();
> >> >>
> >> >> set.remove(EnumFoo.a);
> >> >> iterator.remove(); (1)
> >> >> // The output value is true
> >> >> System.out.println(set.contains(EnumFoo.a));
> >> >> // The output value is 64
> >> >> System.out.println(set.size());
> >> >> }
> >> >> }
> >> >> IMHO, when (1) is executed, an IllegalStateException should be
> thrown
> >> >> out, since the element EnumFoo.a does not exist at the moment.
> >> >> Any thoughts?
> >> >>
> >> >> Best regards
> >> >>
> >> >> --
> >> >> Spark Shen
> >> >> China Software Development Lab, IBM
> >> >>
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> >> For additional commands, e-mail:
> >> harmony-dev-help@incubator.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >> --
> >> Spark Shen
> >> China Software Development Lab, IBM
> >>
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
> >
>
>
> --
> Spark Shen
> China Software Development Lab, IBM
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Leo Li
China Software Development Lab, IBM
Re: [classlib][luni] Suspicious behavior of java.util.EnumSet
Posted by Spark Shen <sm...@gmail.com>.
Leo Li 写道:
> If so, we cannot regard it as RI's bug. And I believe the size of 64
> and the
> existence of the deleted element depends on RI's algorithm especially it
> does not provide concurrent assurance. Maybe it is due to performance
> concerns, I am not sure.
> The curious thing is whether we should behave as RI since it says "it
> may or
> may not show the effects of any modifications to the set that occur while
> the iteration is in progress".
>
>
So, what is your opinion? Should we follow RI on this behavior?
Best regards
> On 8/21/06, Spark Shen <sm...@gmail.com> wrote:
>>
>> Leo Li 写道:
>> > Hi, Spark:
>> > Yes, I think it is RI's bug.
>> > But It should throw ConcurrentModificationException as spec says:
>> > 1. This exception may be thrown by methods that have detected
>> > concurrent modification of an object when such modification is not
>> > permissible.
>> > 2. Note that this exception does not always indicate that an object
>> has
>> > been concurrently modified by a *different* thread. If a single thread
>> > issues a sequence of method invocations that violates the contract
>> of an
>> > object, the object may throw this exception. For example, if a thread
>> > modifies a collection directly while it is iterating over the
>> collection
>> > with a fail-fast iterator, the iterator will throw this exception.
>> >
>> > The iterator 's remove() action relies on the result of previous
>> > next(), but is interrupted by the set.remove() method. I think it
>> is the
>> > case.
>> >
>> > Besides, If the same thing is applied to Hashset:
>> > public static void main(String[] args) {
>> > HashSet set = new HashSet();
>> > Object o = new Object();
>> > set.add(o);
>> > Iterator iter = set.iterator();
>> > iter.next();
>> > set.remove(o);
>> > iter.remove();
>> > }
>> > It will throw ConcurrentModificationException as expected.:)
>> >
>> >
>> There is a paragraph from spec clearly states that
>> ConcurrentModificationException will never be thrown out from the
>> iterator returned
>> by EnumSet. Cited below:
>> "The returned iterator is /weakly consistent/: it will never throw
>> |ConcurrentModificationException|
>> <ci...@gmail.com>
>> and it may or may not show the effects of any modifications to the set
>> that occur while the iteration is in progress."
>>
>> Best regards
>> > On 8/19/06, Spark Shen <sm...@gmail.com> wrote:
>> >>
>> >> Hi All:
>> >> The following behavior of RI java.util.EnumSet seems odd. Do you have
>> >> any opinion on whether it is a bug of RI?
>> >>
>> >> import java.util.EnumSet;
>> >> import java.util.Iterator;
>> >> public class Test {
>> >> static enum EnumFoo {
>> >> a, b,
>> >> }
>> >>
>> >> public static void main(String[] args){
>> >> EnumSet<EnumFoo> set = EnumSet.noneOf(EnumFoo.class);
>> >> set.add(EnumFoo.a);
>> >> Iterator<EnumFoo> iterator = set.iterator();
>> >> iterator.next();
>> >>
>> >> set.remove(EnumFoo.a);
>> >> iterator.remove(); (1)
>> >> // The output value is true
>> >> System.out.println(set.contains(EnumFoo.a));
>> >> // The output value is 64
>> >> System.out.println(set.size());
>> >> }
>> >> }
>> >> IMHO, when (1) is executed, an IllegalStateException should be thrown
>> >> out, since the element EnumFoo.a does not exist at the moment.
>> >> Any thoughts?
>> >>
>> >> Best regards
>> >>
>> >> --
>> >> Spark Shen
>> >> China Software Development Lab, IBM
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail:
>> harmony-dev-help@incubator.apache.org
>> >>
>> >>
>> >
>> >
>>
>>
>> --
>> Spark Shen
>> China Software Development Lab, IBM
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>
--
Spark Shen
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][luni] Suspicious behavior of java.util.EnumSet
Posted by Leo Li <li...@gmail.com>.
If so, we cannot regard it as RI's bug. And I believe the size of 64 and the
existence of the deleted element depends on RI's algorithm especially it
does not provide concurrent assurance. Maybe it is due to performance
concerns, I am not sure.
The curious thing is whether we should behave as RI since it says "it may or
may not show the effects of any modifications to the set that occur while
the iteration is in progress".
On 8/21/06, Spark Shen <sm...@gmail.com> wrote:
>
> Leo Li 写道:
> > Hi, Spark:
> > Yes, I think it is RI's bug.
> > But It should throw ConcurrentModificationException as spec says:
> > 1. This exception may be thrown by methods that have detected
> > concurrent modification of an object when such modification is not
> > permissible.
> > 2. Note that this exception does not always indicate that an object has
> > been concurrently modified by a *different* thread. If a single thread
> > issues a sequence of method invocations that violates the contract of an
> > object, the object may throw this exception. For example, if a thread
> > modifies a collection directly while it is iterating over the collection
> > with a fail-fast iterator, the iterator will throw this exception.
> >
> > The iterator 's remove() action relies on the result of previous
> > next(), but is interrupted by the set.remove() method. I think it is the
> > case.
> >
> > Besides, If the same thing is applied to Hashset:
> > public static void main(String[] args) {
> > HashSet set = new HashSet();
> > Object o = new Object();
> > set.add(o);
> > Iterator iter = set.iterator();
> > iter.next();
> > set.remove(o);
> > iter.remove();
> > }
> > It will throw ConcurrentModificationException as expected.:)
> >
> >
> There is a paragraph from spec clearly states that
> ConcurrentModificationException will never be thrown out from the
> iterator returned
> by EnumSet. Cited below:
> "The returned iterator is /weakly consistent/: it will never throw
> |ConcurrentModificationException| <ci...@gmail.com>
> and it may or may not show the effects of any modifications to the set
> that occur while the iteration is in progress."
>
> Best regards
> > On 8/19/06, Spark Shen <sm...@gmail.com> wrote:
> >>
> >> Hi All:
> >> The following behavior of RI java.util.EnumSet seems odd. Do you have
> >> any opinion on whether it is a bug of RI?
> >>
> >> import java.util.EnumSet;
> >> import java.util.Iterator;
> >> public class Test {
> >> static enum EnumFoo {
> >> a, b,
> >> }
> >>
> >> public static void main(String[] args){
> >> EnumSet<EnumFoo> set = EnumSet.noneOf(EnumFoo.class);
> >> set.add(EnumFoo.a);
> >> Iterator<EnumFoo> iterator = set.iterator();
> >> iterator.next();
> >>
> >> set.remove(EnumFoo.a);
> >> iterator.remove(); (1)
> >> // The output value is true
> >> System.out.println(set.contains(EnumFoo.a));
> >> // The output value is 64
> >> System.out.println(set.size());
> >> }
> >> }
> >> IMHO, when (1) is executed, an IllegalStateException should be thrown
> >> out, since the element EnumFoo.a does not exist at the moment.
> >> Any thoughts?
> >>
> >> Best regards
> >>
> >> --
> >> Spark Shen
> >> China Software Development Lab, IBM
> >>
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
> >
>
>
> --
> Spark Shen
> China Software Development Lab, IBM
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Leo Li
China Software Development Lab, IBM
Re: [classlib][luni] Suspicious behavior of java.util.EnumSet
Posted by Spark Shen <sm...@gmail.com>.
Leo Li 写道:
> Hi, Spark:
> Yes, I think it is RI's bug.
> But It should throw ConcurrentModificationException as spec says:
> 1. This exception may be thrown by methods that have detected
> concurrent modification of an object when such modification is not
> permissible.
> 2. Note that this exception does not always indicate that an object has
> been concurrently modified by a *different* thread. If a single thread
> issues a sequence of method invocations that violates the contract of an
> object, the object may throw this exception. For example, if a thread
> modifies a collection directly while it is iterating over the collection
> with a fail-fast iterator, the iterator will throw this exception.
>
> The iterator 's remove() action relies on the result of previous
> next(), but is interrupted by the set.remove() method. I think it is the
> case.
>
> Besides, If the same thing is applied to Hashset:
> public static void main(String[] args) {
> HashSet set = new HashSet();
> Object o = new Object();
> set.add(o);
> Iterator iter = set.iterator();
> iter.next();
> set.remove(o);
> iter.remove();
> }
> It will throw ConcurrentModificationException as expected.:)
>
>
There is a paragraph from spec clearly states that
ConcurrentModificationException will never be thrown out from the
iterator returned
by EnumSet. Cited below:
"The returned iterator is /weakly consistent/: it will never throw
|ConcurrentModificationException| <ci...@gmail.com>
and it may or may not show the effects of any modifications to the set
that occur while the iteration is in progress."
Best regards
> On 8/19/06, Spark Shen <sm...@gmail.com> wrote:
>>
>> Hi All:
>> The following behavior of RI java.util.EnumSet seems odd. Do you have
>> any opinion on whether it is a bug of RI?
>>
>> import java.util.EnumSet;
>> import java.util.Iterator;
>> public class Test {
>> static enum EnumFoo {
>> a, b,
>> }
>>
>> public static void main(String[] args){
>> EnumSet<EnumFoo> set = EnumSet.noneOf(EnumFoo.class);
>> set.add(EnumFoo.a);
>> Iterator<EnumFoo> iterator = set.iterator();
>> iterator.next();
>>
>> set.remove(EnumFoo.a);
>> iterator.remove(); (1)
>> // The output value is true
>> System.out.println(set.contains(EnumFoo.a));
>> // The output value is 64
>> System.out.println(set.size());
>> }
>> }
>> IMHO, when (1) is executed, an IllegalStateException should be thrown
>> out, since the element EnumFoo.a does not exist at the moment.
>> Any thoughts?
>>
>> Best regards
>>
>> --
>> Spark Shen
>> China Software Development Lab, IBM
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>
--
Spark Shen
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][luni] Suspicious behavior of java.util.EnumSet
Posted by Leo Li <li...@gmail.com>.
Hi, Spark:
Yes, I think it is RI's bug.
But It should throw ConcurrentModificationException as spec says:
1. This exception may be thrown by methods that have detected
concurrent modification of an object when such modification is not
permissible.
2. Note that this exception does not always indicate that an object has
been concurrently modified by a *different* thread. If a single thread
issues a sequence of method invocations that violates the contract of an
object, the object may throw this exception. For example, if a thread
modifies a collection directly while it is iterating over the collection
with a fail-fast iterator, the iterator will throw this exception.
The iterator 's remove() action relies on the result of previous
next(), but is interrupted by the set.remove() method. I think it is the
case.
Besides, If the same thing is applied to Hashset:
public static void main(String[] args) {
HashSet set = new HashSet();
Object o = new Object();
set.add(o);
Iterator iter = set.iterator();
iter.next();
set.remove(o);
iter.remove();
}
It will throw ConcurrentModificationException as expected.:)
On 8/19/06, Spark Shen <sm...@gmail.com> wrote:
>
> Hi All:
> The following behavior of RI java.util.EnumSet seems odd. Do you have
> any opinion on whether it is a bug of RI?
>
> import java.util.EnumSet;
> import java.util.Iterator;
> public class Test {
> static enum EnumFoo {
> a, b,
> }
>
> public static void main(String[] args){
> EnumSet<EnumFoo> set = EnumSet.noneOf(EnumFoo.class);
> set.add(EnumFoo.a);
> Iterator<EnumFoo> iterator = set.iterator();
> iterator.next();
>
> set.remove(EnumFoo.a);
> iterator.remove(); (1)
> // The output value is true
> System.out.println(set.contains(EnumFoo.a));
> // The output value is 64
> System.out.println(set.size());
> }
> }
> IMHO, when (1) is executed, an IllegalStateException should be thrown
> out, since the element EnumFoo.a does not exist at the moment.
> Any thoughts?
>
> Best regards
>
> --
> Spark Shen
> China Software Development Lab, IBM
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Leo Li
China Software Development Lab, IBM