| Summary: | EMF binary compatibility Error | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Brian Lima <blima> | ||||||||||
| Component: | Tools | Assignee: | Dave Steinberg <davidms> | ||||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||||
| Severity: | major | ||||||||||||
| Priority: | P3 | CC: | dccooper | ||||||||||
| Version: | unspecified | ||||||||||||
| Target Milestone: | --- | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows XP | ||||||||||||
| Whiteboard: | |||||||||||||
| Bug Depends on: | |||||||||||||
| Bug Blocks: | 296296 | ||||||||||||
| Attachments: |
|
||||||||||||
Created attachment 152952 [details]
Test project
Created attachment 153019 [details]
Patches to address the issue.
I think it needs to be more like this.
Created attachment 153185 [details]
Alternative fix
Created attachment 153186 [details]
mylyn/context/zip
Ed, I like your first change, but I'm not so sure about the second one. Isn't it better to name the field for the local reference, not the opposite, since it's the local reference that's guaranteed to be unique? Consider the case where C defines another reference, DReference, to another class D, and its opposite is also called CReference. That could result in two fields called EOFFSET_CORRECTION_CREFERENCE_OPPOSITE. It would be much better to have EOFFSET_CORRECTION_BREFERENCE_OPPOSITE and EOFFSET_CORRECTION_DREFERENCE_OPPOSITE. I've attached a patch where I've restored the field's original name and changed all the uses of the field to match. Does this seem reasonable? Ed was happy with my changes, so I have committed the fix. The fix is in CVS for EMF 2.6. (In reply to comment #6) > Ed was happy with my changes, so I have committed the fix. > > The fix is in CVS for EMF 2.6. We'll need to have a patch created for the EMF delivered for Eclipse 3.4.x Please create a duplicate bug for the 2.4 stream, against which I can commit a fix, and then we'll work through the process of delivering it internally. I have created the duplicate: bug 296296. Fix available in HEAD: 2.6.0.I200911261507. |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 Build Identifier: Eclipse 3.4.x Test case: I created the following two models Model A Model B Class A (ie. Catentry) Class B extends Class A (MyCompanyCatentry) Class C references Class B (XWarranty) When the 'binary compatible reflective methods' option is selected on genmodel B, the generated CImpl class has compilation errors. It makes reference to an offset constant that is never defined in the class. For example, "EOFFSET_CORRECTION_CREFERENCE_OPPOSITE" is never defined in CImpl.java /** * <!-- begin-user-doc --> * <!-- end-user-doc --> * @generated */ public void setBReference(B newBReference) { if (newBReference != bReference) { NotificationChain msgs = null; if (bReference != null) msgs = ((InternalEObject)bReference).eInverseRemove(this, BPackage.B__CREFERENCE + EOFFSET_CORRECTION_CREFERENCE_OPPOSITE, B.class, msgs); if (newBReference != null) msgs = ((InternalEObject)newBReference).eInverseAdd(this, BPackage.B__CREFERENCE + EOFFSET_CORRECTION_CREFERENCE_OPPOSITE, B.class, msgs); msgs = basicSetBReference(newBReference, msgs); if (msgs != null) msgs.dispatch(); } else if (eNotificationRequired()) eNotify(new ENotificationImpl(this, Notification.SET, BPackage.C__BREFERENCE, newBReference, newBReference)); } Reproducible: Always