ResourceSetImpl.save gives non-deterministic xml result

[Surcouf01]

We have been working with EMF model to convert from one legacy application to ECOA model stored internally as EMF.
The code we use to save ComponentImplementation (step4) is the same for other ECOA steps and is straigth forward:

        Resource.Factory.Registry reg = Resource.Factory.Registry.INSTANCE;
        Map<String, Object> m = reg.getExtensionToFactoryMap();
        m.put(extension, new XMIResourceFactoryImpl());

        // Obtain a new resource set
        ResourceSet resSet = new ResourceSetImpl();

        // create a resource
        String filename = filePath.getAbsolutePath();
        var resource = resSet.createResource(URI.createFileURI(filename));

        // Get the first model element and cast it to the right type
        resource.getContents().add(object);

        // now save the content.
        Map<String, Object> saveOptions = new HashMap<>();
        saveOptions.put(XMLResource.OPTION_EXTENDED_META_DATA, Boolean.TRUE);
        saveOptions.put(XMLResource.OPTION_ENCODING, UTF_8);
        saveOptions.put(XMIResource.OPTION_SUPPRESS_XMI, Boolean.TRUE);
        saveOptions.put(XMLResource.OPTION_SAVE_TYPE_INFORMATION, Boolean.FALSE);

        resource.save(saveOptions);

The fact is that it generates random xml output (Structure is ok, but it's layed out randomly between runs).
Is there a way to avoid that the saved xml file has a random lay out ?

[merks]

The method org.eclipse.emf.ecore.xmi.impl.XMIResourceImpl.useIDs() is specialized to return true so new XMI IDs will be generated when you do resource.getContents().add(object). Maybe XMLResourceFactoryImpl is a better fit for your application?

[Surcouf01]

Thanks for the reply, we don't use XMI as we set (XMIResource.OPTION_SUPPRESS_XMI, Boolean.TRUE);
I am investigating the overloading of XMLResourceFactoryImpl as you suggested, but I face the need to provide a Comparator (needed by the SortedMap I want to use) and I don't seem to find a good compare implementation based on EObject, if you have one I'll use it.

[Surcouf01]

Apparently EObject provides an implementation of toString(), I used it and apparently it fixed the problem.

[Surcouf01]

Apparently I fixed the issue by overriding the Factory, here is my code.

		m.put(extension, new XMIResourceFactoryImpl(){
			@Override
			public Resource createResource(URI uri) {
				return new XMLResourceImpl(uri) {
					@Override
					public Map<EObject, AnyType> getEObjectToExtensionMap() {
						if (this.eObjectToExtensionMap == null) {
							this.eObjectToExtensionMap = new TreeMap<>(new Comparator<EObject>() {
								@Override
								public int compare(EObject o1, EObject o2) {
									return o1.toString().compareTo(o2.toString());
								}
							});
						}
						return this.eObjectToExtensionMap;
					}

					@Override
					public Map<EObject, String> getEObjectToIDMap() {
						if (this.eObjectToIDMap == null) {
							this.eObjectToIDMap = new TreeMap<>(new Comparator<EObject>() {
								@Override
								public int compare(EObject o1, EObject o2) {
									return o1.toString().compareTo(o2.toString());
								}
							});
						}
						return this.eObjectToIDMap;
					}
				};
			}
		});

My preliminary tests shows that the output is from now on deterministic.

[Surcouf01]

I believe this solution should be incorporated into the EMF library.

[merks]

I'm not sure from where exactly the non-determistic behavior comes because you've not shown any reproducible examples nor samples of serializations that are difference in some way.

Maybe this map in org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.getEObjectToExtensionMap() should be a LinkedHashMap

  public Map<EObject, AnyType> getEObjectToExtensionMap()
  {
    if (eObjectToExtensionMap == null)
    {
      eObjectToExtensionMap = new HashMap<EObject, AnyType>();
    }
    return eObjectToExtensionMap;
  }

Perhaps the ID map as well, but I don't know how the ID map's order has any impact on serialization; I think it does...

Can you try in an override as the only change:

  public Map<EObject, AnyType> getEObjectToExtensionMap()
  {
    if (eObjectToExtensionMap == null)
    {
      eObjectToExtensionMap = new LinkedHashMap<EObject, AnyType>();
    }
    return eObjectToExtensionMap;
  }

But again, I don't see where this order affects serialization. The map is used to look up associated data...

I can only change things if there is a test case demonstrating a behavior that ought to be improved...

[Surcouf01]

To provide a reproducible case I would have to deliver our application with sample test case, but I don't believe I'm allowed as this is proprietary information. I will ask nevertheless.

[Surcouf01]

I implemented what you suggested and after 2 tries I can say that non-deterministic behavior seem to be fixed with this solution as well.
My concern is fixed and I advocate that others may face similar issue, but it's up to you to integrate this change or not.
Thanks for your suggestion anyway.

[merks]

I only ever see that map being used via a Map.get. Could you at least give me some hint via an anonymized XML serialization that highlights the parts that are non-deterministic? If you change the elements names, the attribute names, and the values to something neutral it should be possible to share it without share any trade secrets. When I make changes to the framework, I really need to understand why I'm making them and in this case I see nothing that changes as a result of the order of this map. Maybe your frameworks are processing that map directly in some way?

[merks]

Gentle (and last) nudge. If you want something changed in the framework I at least need to understand why serialization is impacted by order when it doesn't appear that order matters anywhere...