Reduce JavaContextDependentURIFragmentFactory Instances

[BenjaminKlatt]

Background

Currently, everytime a JavaContextDependentURIFragmentFactory is required a new instance is created in the JaMoPP code.
This leads to a new Factory for each URIFragement during code parsing.

A code review showd that the typed JavaContextDependentURIFragmentFactory is thread safe due to it's stateless processing.
A single instance per type could be used.

JavaParser

In the current implementation, new instances are created for each method call, for example of the parse methods of the JavaParser.

For example in parse_org_emftext_language_java_annotations_AnnotationAttributeSetting() each method invocation creates a new JavaContextDependentURIFragmentFactory instance:

registerContextDependentProxy(new org.emftext.language.java.resource.java.mopp.JavaContextDependentURIFragmentFactory<org.emftext.language.java.annotations.AnnotationAttributeSetting, org.emftext.language.java.members.InterfaceMethod>(getReferenceResolverSwitch() == null ? null : getReferenceResolverSwitch().getAnnotationAttributeSettingAttributeReferenceResolver()), element, (org.eclipse.emf.ecore.EReference) element.eClass().getEStructuralFeature(org.emftext.language.java.annotations.AnnotationsPackage.ANNOTATION_ATTRIBUTE_SETTING__ATTRIBUTE), resolved, proxy);

The typed JavaContextDependentURIFragmentFactory is always the same for a specific parse method and could be instantiated per JavaParser instance.

getReferenceResolverSwitch() always return the same switch instance provided by the metaInformation which is not null and the same for each ParserInstance. (see #16)
This allows to simplify the instantiation of the typed JavaContextDependentURIFragmentFactory per JavaParser instance.

JavaContextDependentURIFragmentFactory

Another code location instantiating JavaContextDependentURIFragmentFactory instances is in JavaResourcePostProcessor.
This can also be optimized by using a single instance of this factory per JavaResourcePostProcessor instance.

Optimization Result

The modifications lead to a static number of factory instances, independend of the number of processed java elements.
With the ArgoUML SPLevo/KoPL case study, this is more than 0.5 billion object instances (increasing, total number not available because parsing not possible yet).