[ENK-6] Attribute and Associations are generated in different orders across JVMs

[dynamobi-build]

[reporter="stephan", created="Fri, 5 Dec 2008 18:58:33 -0500 (GMT-05:00)"]
Attribute and Associations are generated in different orders across JVMs.

Attribute parameter ordering in factory methods for class proxies vary across JVMs. This happens intermittently. See IceCreamCone references in ENK-3. In general, this likely means the Attributes are varying in order as well. It should only be visible for a) the factory methods already mentioned, and b) for event ordering for Attributes with a type that is a Classifier from the model itself.

Associations are generated in varying orders across JVMs as well. This happens more regularly and causes the MdrEventApiTest failure seen with the Sun JDK -- the eem.sample.special.Floor is firing events in order of associations found in the model and since the test requires it to fire events for two associations, reversing them causes the exception. (Also noted in ENK-3.)

Paths of investigation:
- Is this caused by XSLT output variation across JVMs? If so, is the variation unexpected (e.g., is the re-ordering ordered elements in the XML an XSLT script or XSLT processor bug) or expected (in which case can XSLT be modified to maintain order or should code gen sort the objects)
- If XMI input is constant, is MDR re-ordering elements that it shouldn't or is it Enki code gen?

[dynamobi-build]

[author="stephan", created="Fri, 5 Dec 2008 19:12:24 -0500 (GMT-05:00)"]
The issue comes when converting the UML sans diagrams to XMI format. Depending on the VM, ordering may change. In fact, FRG-322 indicates that it can happen at least occassionally with the same VM.

[dynamobi-build]

[author="stephan", created="Fri, 5 Dec 2008 19:21:52 -0500 (GMT-05:00)"]
Correction, during the UML2MOF step. The intermediate file immediately preceding this step (UML sans diagrams) is identical across the JVMs, but the output of

org.netbeans.lib.jmi.uml2mof.Main

varies by JVM.

[dynamobi-build]

[author="stephan", created="Fri, 5 Dec 2008 19:39:19 -0500 (GMT-05:00)"]
The uml2mof utility from Netbeans stores all of its intermediate data in HashMap instances. I suspect that if there were LinkedHashMap instances (or TreeMap instances, assuming an appropriate Comparator could be written), then the variation would be eliminated. Can only do this be resurrecting the Netbeans mdr/extras/uml2mof build. It only consists of two classes, so this is probably feasible.

[dynamobi-build]

[author="jvs", created="Sat, 6 Dec 2008 15:28:10 -0500 (GMT-05:00)"]
I've given you write access to //open/uml2mof/... in case you want a separate place to check modified code in (like I did with //open/mdrjdbc). The uml2mof code has to stay under its original Sun Public License. (It was later changed to CDDL, but I don't think any code changed, so the earlier SPL copy is preferred since we already have the GPL exception for that written into the Eigenbase COPYING file.

[dynamobi-build]

[author="stephan", created="Tue, 9 Dec 2008 16:40:44 -0500 (GMT-05:00)"]
I may have to retract my statements re: uml2mof. Today, I've seen the "IceCreamCone" failure a few times in the Sun JDK. Each time, a copy of the output of the original uml2mof program has IceCreamCone's attributes in the correct order. And the file is identical to the version produced by JRockit. Not sure why I was seeing massive differences before.

Trace output added to HibernateJavaHandler (and GeneratorBase) implies that the ordering of the Attributes in the IceCreamCone MofClass is incorrect in the collections returned from NetBeans MDR.

[dynamobi-build]

[author="jvs", created="Tue, 9 Dec 2008 16:47:18 -0500 (GMT-05:00)"]
I just heard the sound of wild geese passing overhead.

[dynamobi-build]

[author="stephan", created="Tue, 9 Dec 2008 17:07:20 -0500 (GMT-05:00)"]
Shoot me now. I was copying the wrong file in my previous test. So, the output of uml2mof is really very different when the error occurs, and in particular the attributes of the IceCreamCone class are in a different order. So, something about uml2mof is the culprit.

[dynamobi-build]

[author="stephan", created="Tue, 9 Dec 2008 19:47:24 -0500 (GMT-05:00)"]
Verified that XmiReader calls refAddLink on the "A_owner_feature" association in the correct order and that subsequently, calling getFeature() on the MofClass (the owner end of the association) returns the Attributes (the feature end of the association) in a different order.

[dynamobi-build]

[author="stephan", created="Tue, 9 Dec 2008 20:40:04 -0500 (GMT-05:00)"]
Fairly certain this is NBMDR btree bug. The btree index data is stored in a big byte array and when it inserts into the index correctly the offsets are X, X+8 and X+16. When it fails, it inserts at X, X+8 and X+8, effectively inserting the third Attribute in between the first and second. Not sure why -- perhaps when the btree page has been split and the first and second values aren't on the same page it doesn't look on the next page or something.

[dynamobi-build]

[author="stephan", created="Wed, 10 Dec 2008 13:36:43 -0500 (GMT-05:00)"]
This problem exists in Enki code generation as well, since it imports XMI into a Netbeans btree repository.

Possible solutions, in increasing order of effort:
1. Use Netbeans memory repository implementation
2. Use Netbeans against MDRJDBC+HSQLDB
3. Switch to using Enki/Hibernate UML model import and conversion.

Option 1 seems to work well for UML2MOF, and is the fastest fix (just add a system property). Still want to do #3 some day so that we can jettison Netbeans altogether.

Will test #1 with Enki code gen before checking in any changes.

[dynamobi-build]

[author="stephan", created="Wed, 10 Dec 2008 16:31:16 -0500 (GMT-05:00)"]
Fixed in Enki @ 12076.

Build now invoked uml2mof with system properties that configure memory repository and Enki code gen does the same in MdrGenerator.

[dynamobi-build]

[author="stephan", created="Wed, 10 Dec 2008 16:33:09 -0500 (GMT-05:00)"]
Oops make that 12078.