ClassCastException with flatten

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 373968 | | Status | NEW | | Importance | P3 normal | | Reported | Mar 12, 2012 10:42 EDT | | Modified | Jun 17, 2014 04:57 EDT | | Reporter | Stephane Begaudeau |

Description

In Acceleo, the following expression throws a ClassCastException:\ [Sequence{Sequence{'a', 'b'}, 'c'}->flatten()/]

java.lang.ClassCastException: java.lang.String cannot be cast to java.util.Collection\ at org.eclipse.ocl.util.CollectionUtil.flatten(CollectionUtil.java:425)\ at org.eclipse.ocl.EvaluationVisitorImpl.visitOperationCallExp(EvaluationVisitorImpl.java:491)\ at org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitOperationCallExp(AcceleoEvaluationVisitor.java:1189)

[eclipse-ocl-bot]

By Ed Willink on Mar 12, 2012 10:58

The support for nested collections in the Ecore-binding is indeed suspect and one of the motivations for the pivot binding. The legacy implementation uses Java objects directly and so gets confused about Collection/Object distinctions that were illegal in OCL 2.0 for which the code was designed. The pivot has Value objects throughout and so no confusion.

The utility of nested collections is highly suspect. In the given example

Sequence{Sequence{'a', 'b'}, 'c'}

is a Sequence(OclAny) since OclAny is the only common type for Sequence(String) and String.

I find the OCL 2.2 innovation that Collection conforms to OclAny is largely undesirable. I'm wondering whether the required polymorphism is better supported by a Tree collection type so that Sequence{Sequence{'a', 'b'}, 'c'} is a Tree(String) for which Tree could provide regular operations.

Almost certainly WONTFIX, but leaning open to preserve the Tree requirement.

[eclipse-ocl-bot]

By Ed Willink on Jun 17, 2014 04:57

The fix to CollectionUtil is actually very simple; the current code does not support arbitrarily nested or heteogeneous collections.

The code also does not support OrderedSet although the introductory comment excplains how the lack of OCL specification means that the design chooses to support OrderedSet sensibly.

Correcting the OrderedSet flattening causes 5 JUnit test failures because the tests expects a Set return.

The reported bug is easy to fix but hard to test, since the parser cannot find a common supertype when creating a heterogeneous collection.

The OrderedSet bug fix is breaking. Do we need yet another keep-the-bug preference option?

We could leave OrderedSet broken; the fixes to heterogeneous collection mainly break existing usage by not giving a CCE, but also by correctly flattening doubly nested collections.

Fix parked in archive/373968 pending opinions on when or how to proceed.