Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » java.util.ConcurrentModificationException
java.util.ConcurrentModificationException [message #63322] Thu, 23 October 2008 11:50 Go to next message
Mark Melia is currently offline Mark Melia
Messages: 142
Registered: July 2009
Senior Member
Hi All,

I am trying to allow for OCL constraints to be changed at runtime in my
application. I think that the constraints are getting stored (cached) in
the category so if a constraint is changed it keeps the old one. Everytime
I try and remove the constraints from the category I get the
java.util.ConcurrentModificationException exception. I am trying to remove
the constraints in the BatchValidationDelegate class, if that helps.

Does anyone know whats going on?

Thanks,
Mark
Re: java.util.ConcurrentModificationException [message #63346 is a reply to message #63322] Mon, 27 October 2008 11:25 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.zeligsoft.com

Hi, Mark,

This sounds like an EMF Validation Framework question, so I am including
that newsgroup in my reply.

If you are only changing the definition of the OCL constraint, then you
shouldn't need to remove its descriptor, but just its IModelConstraint
implementation. How to do that depends on how you have implemented the
constraint.

The out-of-the-box OCL support provided by the
org.eclipse.emf.validation.ocl feature assumes that OCL constraints are
statically defined and won't change, because they are part of or
extensions to the target model. If you're currently using that, then
your best bet may be to desist and implement your own OCL constraint
provider. This could be a dynamic constraint provider, after the
fashion of the org.eclipse.emf.validation.examples.ocl example, or by
defining your own "constraint language" on the
org.eclipse.emf.validation.parsers extension point. Either way, you
will have control over the constraint implementation, so that you can
make its guts more flexible without confusing the outside world by
messing with constraint descriptors.

In any case, it should be possible to manipulate the constraint
descriptors and categories in the way that you need. Can you provide a
stack trace, and maybe a code snippet? I haven't seen this particular
problem, before.

Cheers,

Christian

Mark Melia wrote:
> Hi All,
>
> I am trying to allow for OCL constraints to be changed at runtime in my
> application. I think that the constraints are getting stored (cached) in
> the category so if a constraint is changed it keeps the old one.
> Everytime I try and remove the constraints from the category I get the
> java.util.ConcurrentModificationException exception. I am trying to
> remove the constraints in the BatchValidationDelegate class, if that helps.
>
> Does anyone know whats going on?
>
> Thanks,
> Mark
>
Re: java.util.ConcurrentModificationException [message #63436 is a reply to message #63346] Tue, 28 October 2008 12:05 Go to previous messageGo to next message
Mark Melia is currently offline Mark Melia
Messages: 142
Registered: July 2009
Senior Member
Hi Christian,

Thanks for your reply.

> If you are only changing the definition of the OCL constraint, then you
> shouldn't need to remove its descriptor, but just its IModelConstraint
> implementation. How to do that depends on how you have implemented the
> constraint.

I may want to add new OCL constraints and delete existing ones - I think
then there is a case for removing the descriptor.

We are using and extending the org.eclipse.emf.validation.examples.ocl
example. Keeping this in mind to remove constraints I have extended the
parseConstraints method in the OCLConstraintProvider.

I should note that the exception does not always happen, after 2 or 3
validation the exception (after code snippet) is thrown.

Thanks,
Mark

private void parseConstraints(Category category, String namespace,
InputStream input) throws ParserException {

OCLInput oclInput = new OCLInput(input);

OCL ocl = OCL.newInstance();
ArrayList <String> thisConstraints = new ArrayList<String>();

for (Constraint constraint : ocl.parse(oclInput)) {
if (isInvariant(constraint)) {
// only add invariant constraints for validation
thisConstraints.add(constraint.getName());
addConstraint(category, namespace, ocl, constraint);
}
}
java.util.Iterator <IModelConstraint> itr = constraints.iterator();
while(itr.hasNext()){
IModelConstraint c = (IModelConstraint)itr.next();

if(!thisConstraints.contains(c.getDescriptor().getName())){
System.out.println("getting rid of "+c.getDescriptor().getName());
constraints.remove(c);
}
}
}

Stack trace:
java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(AbstractLi st.java:449)
at java.util.AbstractList$Itr.next(AbstractList.java:420)
at
org.eclipse.emf.validation.examples.ocl.OCLConstraintProvide r.parseConstraints(OCLConstraintProvider.java:149)
at
org.eclipse.emf.validation.examples.ocl.OCLConstraintProvide r.parseConstraints(OCLConstraintProvider.java:113)
at
org.eclipse.emf.validation.examples.ocl.OCLConstraintProvide r.getConstraints(OCLConstraintProvider.java:87)
at
org.eclipse.emf.validation.service.AbstractConstraintProvide r.getBatchConstraints(AbstractConstraintProvider.java:328)
at
org.eclipse.emf.validation.internal.service.GetBatchConstrai ntsOperation.executeImpl(GetBatchConstraintsOperation.java:5 7)
at
org.eclipse.emf.validation.internal.service.AbstractGetConst raintsOperation.execute(AbstractGetConstraintsOperation.java :132)
at
org.eclipse.emf.validation.service.ModelValidationService.ex ecute(ModelValidationService.java:398)
at
org.eclipse.emf.validation.service.ModelValidationService.ac cess$2(ModelValidationService.java:392)
at
org.eclipse.emf.validation.service.ModelValidationService$1. execute(ModelValidationService.java:206)
at
org.eclipse.emf.validation.internal.service.AbstractValidato r.execute(AbstractValidator.java:287)
at
org.eclipse.emf.validation.internal.service.BatchValidator.v alidate(BatchValidator.java:238)
at
org.eclipse.emf.validation.internal.service.BatchValidator.v alidate(BatchValidator.java:194)
at
org.eclipse.emf.validation.internal.service.BatchValidator.d oValidate(BatchValidator.java:139)
at
org.eclipse.emf.validation.internal.service.AbstractValidato r.validate(AbstractValidator.java:140)
at
org.eclipse.emf.validation.examples.general.actions.BatchVal idationDelegate.run(BatchValidationDelegate.java:210)
at
org.eclipse.emf.validation.examples.general.actions.BatchVal idationDelegate.runWithEvent(BatchValidationDelegate.java:16 3)
at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginActi on.java:241)
at
org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:583)
at
org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:500)
at
org.eclipse.jface.action.ActionContributionItem$5.handleEven t(ActionContributionItem.java:411)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1561)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1585)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1570)
at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1 360)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3474)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3064)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2382)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2346)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:21 98)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:488)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
at
org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:113)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:110)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:79)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:382)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 549)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
at org.eclipse.equinox.launcher.Main.main(Main.java:1212)

> The out-of-the-box OCL support provided by the
> org.eclipse.emf.validation.ocl feature assumes that OCL constraints are
> statically defined and won't change, because they are part of or
> extensions to the target model. If you're currently using that, then
> your best bet may be to desist and implement your own OCL constraint
> provider. This could be a dynamic constraint provider, after the
> fashion of the org.eclipse.emf.validation.examples.ocl example, or by
> defining your own "constraint language" on the
> org.eclipse.emf.validation.parsers extension point. Either way, you
> will have control over the constraint implementation, so that you can
> make its guts more flexible without confusing the outside world by
> messing with constraint descriptors.

> In any case, it should be possible to manipulate the constraint
> descriptors and categories in the way that you need. Can you provide a
> stack trace, and maybe a code snippet? I haven't seen this particular
> problem, before.

> Cheers,

> Christian

> Mark Melia wrote:
>> Hi All,
>>
>> I am trying to allow for OCL constraints to be changed at runtime in my
>> application. I think that the constraints are getting stored (cached) in
>> the category so if a constraint is changed it keeps the old one.
>> Everytime I try and remove the constraints from the category I get the
>> java.util.ConcurrentModificationException exception. I am trying to
>> remove the constraints in the BatchValidationDelegate class, if that helps.
>>
>> Does anyone know whats going on?
>>
>> Thanks,
>> Mark
>>
Re: java.util.ConcurrentModificationException [message #63505 is a reply to message #63436] Tue, 28 October 2008 13:48 Go to previous messageGo to next message
Mark Melia is currently offline Mark Melia
Messages: 142
Registered: July 2009
Senior Member
Hi all,

Sorry silly error - I was manipulating the arraylist while iterating it.

Mark

Mark Melia wrote:

> Hi Christian,

> Thanks for your reply.

>> If you are only changing the definition of the OCL constraint, then you
>> shouldn't need to remove its descriptor, but just its IModelConstraint
>> implementation. How to do that depends on how you have implemented the
>> constraint.

> I may want to add new OCL constraints and delete existing ones - I think
> then there is a case for removing the descriptor.

> We are using and extending the org.eclipse.emf.validation.examples.ocl
> example. Keeping this in mind to remove constraints I have extended the
> parseConstraints method in the OCLConstraintProvider.

> I should note that the exception does not always happen, after 2 or 3
> validation the exception (after code snippet) is thrown.

> Thanks,
> Mark

> private void parseConstraints(Category category, String namespace,
> InputStream input) throws ParserException {

> OCLInput oclInput = new OCLInput(input);

> OCL ocl = OCL.newInstance();
> ArrayList <String> thisConstraints = new ArrayList<String>();

> for (Constraint constraint : ocl.parse(oclInput)) {
> if (isInvariant(constraint)) {
> // only add invariant constraints for validation
> thisConstraints.add(constraint.getName());
> addConstraint(category, namespace, ocl, constraint);
> }
> }
> java.util.Iterator <IModelConstraint> itr = constraints.iterator();
> while(itr.hasNext()){
> IModelConstraint c = (IModelConstraint)itr.next();

> if(!thisConstraints.contains(c.getDescriptor().getName())){
> System.out.println("getting rid of "+c.getDescriptor().getName());
> constraints.remove(c);
> }
> }
> }

> Stack trace:
> java.util.ConcurrentModificationException
> at java.util.AbstractList$Itr.checkForComodification(AbstractLi st.java:449)
> at java.util.AbstractList$Itr.next(AbstractList.java:420)
> at
>
org.eclipse.emf.validation.examples.ocl.OCLConstraintProvide r.parseConstraints(OCLConstraintProvider.java:149)
> at
>
org.eclipse.emf.validation.examples.ocl.OCLConstraintProvide r.parseConstraints(OCLConstraintProvider.java:113)
> at
>
org.eclipse.emf.validation.examples.ocl.OCLConstraintProvide r.getConstraints(OCLConstraintProvider.java:87)
> at
>
org.eclipse.emf.validation.service.AbstractConstraintProvide r.getBatchConstraints(AbstractConstraintProvider.java:328)
> at
>
org.eclipse.emf.validation.internal.service.GetBatchConstrai ntsOperation.executeImpl(GetBatchConstraintsOperation.java:5 7)
> at
>
org.eclipse.emf.validation.internal.service.AbstractGetConst raintsOperation.execute(AbstractGetConstraintsOperation.java :132)
> at
>
org.eclipse.emf.validation.service.ModelValidationService.ex ecute(ModelValidationService.java:398)
> at
>
org.eclipse.emf.validation.service.ModelValidationService.ac cess$2(ModelValidationService.java:392)
> at
>
org.eclipse.emf.validation.service.ModelValidationService$1. execute(ModelValidationService.java:206)
> at
>
org.eclipse.emf.validation.internal.service.AbstractValidato r.execute(AbstractValidator.java:287)
> at
>
org.eclipse.emf.validation.internal.service.BatchValidator.v alidate(BatchValidator.java:238)
> at
>
org.eclipse.emf.validation.internal.service.BatchValidator.v alidate(BatchValidator.java:194)
> at
>
org.eclipse.emf.validation.internal.service.BatchValidator.d oValidate(BatchValidator.java:139)
> at
>
org.eclipse.emf.validation.internal.service.AbstractValidato r.validate(AbstractValidator.java:140)
> at
>
org.eclipse.emf.validation.examples.general.actions.BatchVal idationDelegate.run(BatchValidationDelegate.java:210)
> at
>
org.eclipse.emf.validation.examples.general.actions.BatchVal idationDelegate.runWithEvent(BatchValidationDelegate.java:16 3)
> at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginActi on.java:241)
> at
>
org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:583)
> at
>
org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:500)
> at
>
org.eclipse.jface.action.ActionContributionItem$5.handleEven t(ActionContributionItem.java:411)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :84)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1561)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1585)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1570)
> at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1 360)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3474)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3064)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2382)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2346)
> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:21 98)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:488)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
> at
>
org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:113)
> at
>
org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
> at
>
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:110)
> at
>
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:79)
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:382)
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:179)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
> at
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 549)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1212)

>> The out-of-the-box OCL support provided by the
>> org.eclipse.emf.validation.ocl feature assumes that OCL constraints are
>> statically defined and won't change, because they are part of or
>> extensions to the target model. If you're currently using that, then
>> your best bet may be to desist and implement your own OCL constraint
>> provider. This could be a dynamic constraint provider, after the
>> fashion of the org.eclipse.emf.validation.examples.ocl example, or by
>> defining your own "constraint language" on the
>> org.eclipse.emf.validation.parsers extension point. Either way, you
>> will have control over the constraint implementation, so that you can
>> make its guts more flexible without confusing the outside world by
>> messing with constraint descriptors.

>> In any case, it should be possible to manipulate the constraint
>> descriptors and categories in the way that you need. Can you provide a
>> stack trace, and maybe a code snippet? I haven't seen this particular
>> problem, before.

>> Cheers,

>> Christian

>> Mark Melia wrote:
>>> Hi All,
>>>
>>> I am trying to allow for OCL constraints to be changed at runtime in my
>>> application. I think that the constraints are getting stored (cached) in
>>> the category so if a constraint is changed it keeps the old one.
>>> Everytime I try and remove the constraints from the category I get the
>>> java.util.ConcurrentModificationException exception. I am trying to
>>> remove the constraints in the BatchValidationDelegate class, if that helps.
>>>
>>> Does anyone know whats going on?
>>>
>>> Thanks,
>>> Mark
>>>
Re: java.util.ConcurrentModificationException [message #63528 is a reply to message #63505] Tue, 28 October 2008 13:54 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.zeligsoft.com

Hi, Mark,

Yes, I think you wanted iter.remove() instead of constraints.remove(c)

However, it is odd that this happens sporadically -- it looks like a
sure bomb.

You're sure that all is well, now?

cW

Mark Melia wrote:
> Hi all,
>
> Sorry silly error - I was manipulating the arraylist while iterating it.
>
> Mark
>
> Mark Melia wrote:
>

-----8<-----
Re: java.util.ConcurrentModificationException [message #63731 is a reply to message #63528] Thu, 30 October 2008 08:42 Go to previous messageGo to next message
Mark Melia is currently offline Mark Melia
Messages: 142
Registered: July 2009
Senior Member
Hi Christian,

Yeah it was just a stupid coding mistake I made.

One more question for you. In the OCLConstraintProvider you wrote for the
example if you set up an instance list variable to hold all the
constraints and the getConstraints method returns it all the constraints
are registered correctly, however if you set up a local variable to do the
exact same thing it doesn't work.

Also with this instance variable - if you clear it at the start of the
getConstraints method, the constraints again wont be registered correctly.

Any idea what is happening here?
Mark


Christian W. Damus wrote:

> Hi, Mark,

> Yes, I think you wanted iter.remove() instead of constraints.remove(c)

> However, it is odd that this happens sporadically -- it looks like a
> sure bomb.

> You're sure that all is well, now?

> cW

> Mark Melia wrote:
>> Hi all,
>>
>> Sorry silly error - I was manipulating the arraylist while iterating it.
>>
>> Mark
>>
>> Mark Melia wrote:
>>

> -----8<-----
Re: java.util.ConcurrentModificationException [message #63754 is a reply to message #63528] Thu, 30 October 2008 08:47 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5277
Registered: July 2009
Senior Member
The reason for this happening sporadically is that if
constraints.remove(c) is the last action (e.g. because you are already
on the last element and hasNext() returns false, break the loop ...).

The CME is only thrown on the next call to it.next() where the
modification counter of the underlying Collection is checked.

Tom

Christian W. Damus schrieb:
> Hi, Mark,
>
> Yes, I think you wanted iter.remove() instead of constraints.remove(c)
>
> However, it is odd that this happens sporadically -- it looks like a
> sure bomb.
>
> You're sure that all is well, now?
>
> cW
>
> Mark Melia wrote:
>> Hi all,
>>
>> Sorry silly error - I was manipulating the arraylist while iterating it.
>>
>> Mark
>>
>> Mark Melia wrote:
>>
>
> -----8<-----


--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
Re: java.util.ConcurrentModificationException [message #63776 is a reply to message #63754] Thu, 30 October 2008 08:58 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.zeligsoft.com

Hi, Tom,

Yes, that must be it. Collections don't track their iterators, so the
check can't be done on the modify side.

Thanks!

Christian

Tom Schindl wrote:
> The reason for this happening sporadically is that if
> constraints.remove(c) is the last action (e.g. because you are already
> on the last element and hasNext() returns false, break the loop ...).
>
> The CME is only thrown on the next call to it.next() where the
> modification counter of the underlying Collection is checked.
>
> Tom
>
> Christian W. Damus schrieb:
>> Hi, Mark,
>>
>> Yes, I think you wanted iter.remove() instead of constraints.remove(c)
>>
>> However, it is odd that this happens sporadically -- it looks like a
>> sure bomb.
>>
>> You're sure that all is well, now?
>>
>> cW
>>
>> Mark Melia wrote:
>>> Hi all,
>>>
>>> Sorry silly error - I was manipulating the arraylist while iterating it.
>>>
>>> Mark
>>>
>>> Mark Melia wrote:
>>>
>> -----8<-----
>
>
Re: java.util.ConcurrentModificationException [message #63908 is a reply to message #63731] Thu, 30 October 2008 11:39 Go to previous message
Eclipse User
Originally posted by: cdamus.zeligsoft.com

Hi, Mark,

The example OCLConstraintProvider is designed to be dynamic inasmuch as
the constraints it provides are discovered at run-time, buth these
constraints in and of themselves are not changeable (they are just
loaded from text files).

So, you can see that it calls the registerConstraints() method inherited
from the AbstractConstraintProvider in the setInitializationData()
method. This is done exactly once. Moreover, the constraints that it
registers are those that are stared in the superclass's field, a list
that is appended by the addConstraint() method.

If you are maintaining a list of constraints locally in some method,
containing newly-created constraints, then you can use the same
registerConstraints() method to ensure that they are registered.

HTH,

Christian

Mark Melia wrote:
> Hi Christian,
>
> Yeah it was just a stupid coding mistake I made.
>
> One more question for you. In the OCLConstraintProvider you wrote for
> the example if you set up an instance list variable to hold all the
> constraints and the getConstraints method returns it all the constraints
> are registered correctly, however if you set up a local variable to do
> the exact same thing it doesn't work.
>
> Also with this instance variable - if you clear it at the start of the
> getConstraints method, the constraints again wont be registered correctly.
>
> Any idea what is happening here?
> Mark
>
>
> Christian W. Damus wrote:
>
>> Hi, Mark,
>
>> Yes, I think you wanted iter.remove() instead of constraints.remove(c)
>
>> However, it is odd that this happens sporadically -- it looks like a
>> sure bomb.
>
>> You're sure that all is well, now?
>
>> cW
>
>> Mark Melia wrote:
>>> Hi all,
>>>
>>> Sorry silly error - I was manipulating the arraylist while iterating it.
>>>
>>> Mark
>>>
>>> Mark Melia wrote:
>>>
>
>> -----8<-----
>
>
Previous Topic:Which Version of the spec is supported?
Next Topic:where is the ocl editor?
Goto Forum:
  


Current Time: Wed Aug 20 08:53:17 EDT 2014

Powered by FUDForum. Page generated in 0.10967 seconds