Community
Participate
Working Groups
When features are not EClass but only EClassifier-typed, a ClassCastException results. See https://bugs.eclipse.org/bugs/attachment.cgi?id=194447 for a patch that fixes the problem.
There must be some confusion here. You're asking us to break API. This must be the EClass of the EObject, so I don't get that there's a problem.
(In reply to comment #1) > There must be some confusion here. You're asking us to break API. This must > be the EClass of the EObject, so I don't get that there's a problem. That's what I thought too when I first scanned the code, but it isn't the EStructuralFeature.eContainerClass class, it's the EStructuralFeature.eType classifier, so the EClass cast assumes an EReference when setting delegates apply equally well to EAttributes. You can see that the patch just removes a couple of casts eliminating some spurious type assumptions; the compiler is happy that the fewer cast code is better.
Again, you're asking us to break API. We don't generally ever do that and most certainly not without strong justification. There is a guard that's intended to capture all cases of the feature's type being an EDataType else if (eType instanceof EDataType) Before I hear a long story about some EClassifier that's neither an EClass nor an EDataType keep in mind that we've been very clear that the Ecore model is not to be extended, so an EClassifier that is neither an EClass nor an EDataType is not supported and won't be supported.
OK. Thanks for the clarification. Bug 344405 raised to legalize the OCL ecore meta-model. The change appears to introduce only pedantic API change noise that is easily suppressed by comment filters.
