Is it still necessary to bind ISerializer to org.eclipse.xtext.serializer.impl.Serializer?

[tfonda-fbk]

Hi,
In my project I am using ((XtextResource) myEObject.eResource()).getResourceServiceProvider().get(ISerializer.class); to get an instance of the Xtext serializer. I jumped to the definition of the ISerializer interface and stumbled upon the introductory comment. So I headed to my RuntimeModule and quickly overrode bindISerializer(). However, curiosity led me to inspect the default bindISerializer() defined in my DSL's Abstract RuntimeModule, and I found this:

import org.eclipse.xtext.serializer.impl.Serializer;
...
...
	// contributed by org.eclipse.xtext.xtext.generator.serializer.SerializerFragment2
	public Class<? extends ISerializer> bindISerializer() {
		return Serializer.class;
	}

I am confused, it looks like after this commit, SerializerFragment2 is already contributing to my DSL's RuntimeModule the correct binding to the new Serializer class, or am I missing anything? The commit that added that comment in ISerializer.java predates the commit introducing SerializerFragment2 by ~1 year - so I guess the comment is stale and can be removed, together with the SuppressWarnings annotation, and the import in ISerializer can be changed to reference the new impl?

Could anyone shed some light on this, please?
Thanks!

[cdietrich]

i fear nobody knows....

[tfonda-fbk]

I have actually called serializer.getClass().getName() after obtaining my serializer as explained above and without any manually-added binding in the runtime module, and the string I got is indeed org.eclipse.xtext.serializer.impl.Serializer. So I conclude that in "standard" Xtext use cases (where there is, e.g., a MyDSLRuntimeModule that extends AbstractMyDSLRuntimeModule that in turn extends DefaultRuntimeModule), no manual binding is needed. If a case exists, where the DefaultRuntimeModule is used/extended without the presence of the generated Abstract*RuntimeModule, though, then in this case the old, deprecated Serializer implementation is used, as DefaultRuntimeModule still binds the old one.