How to generate Java code from big Ecore models (2000+ classes)?

[mr-cheddar]

Hi all,
how can big Ecore models be used for Java code generation correctly? And is it possible at all?

I have generated an Ecore model with about 2000 Classes and Enums which blows up some generated switch statements in the *PackageImpl and *Switch Java classes. Resulting in errors like:

The code of method ...() is exceeding the 65535 bytes limit

I could divide the Ecore model into several smaller ones and generate each part by itself. But then I would need to take care of each single genmodel and all the changes in the util package classes need to be distributed as well for example. It seems not to be the right way to do it.

Is there anything else I could do in order to generate from 1 big Ecore model? Maybe some option in the genmodel which solves the problem automagically 😉?

[merks]

The GenPackage property Initialize by Loading helps with very large packages:

I've never seen a model that blew up the XyzSwitch.doSwitch, so I have no solution for that. Assuming your model (class hierarchy) is relatively stable, you might manually split up the long doSwitch method..

[mr-cheddar]

Thank you for the hint!

The class hierarchy in my Ecore model is not optimal but the best I can achieve in reasonable time. Since the generation is part of a mainly automated process and the big size of the model I do not want to touch the generated code.

The only left option I see is to adapt the JET templates. Is it possible to specify in the generator model which of my own JET templates should be used for the generation?
There is a property group 'Templates and Merge' with properties like 'Dynamic Templates' and 'Template Directory' but I do not know whether they are about the JET templates, whether they overwrite the default templates and how to use them exactly.

If it is not possible then I guess I will need to adapt the JET templates in the ...codegen.ecore plugin itself.

[merks]

Yes, it's possible to use dynamic templates. UM2 does that:

https://github.com/eclipse-uml2/uml2/blob/fcf904504099e2976951a38129ec3696b4f3e39d/plugins/org.eclipse.uml2.uml/model/UML.genmodel#L5-L6

https://github.com/eclipse-uml2/uml2/tree/master/plugins/org.eclipse.uml2.codegen.ecore/templates

But the documentation on that is sparse at best.

[mr-cheddar]

Here is a simple generated Ecore model BIG.ecore.xml (5000 classes with 10 attributes each) just in case anybody likes to play with the generation performance of big models or test anything else. (I renamed it to '...xml' since ecore files are not allowed for uploading 😅)

Here a snippet for updating the model depending on the 2 variables NUMBER_ATTRIBUTES and NUMBER_CLASSES at the top:

public class BigEcoreModelGenerator {

	public static void main(String[] args) {
		var NUMBER_ATTRIBUTES 	= 5;
		var NUMBER_CLASSES 		= 5000;
		
		var rss = new ResourceSetImpl();
		rss.getResourceFactoryRegistry().getExtensionToFactoryMap().put("ecore", new EcoreResourceFactoryImpl());
		var path = new File("model/BIG.ecore").getAbsolutePath();
		var uri = URI.createFileURI(path);
		var bigResource = rss.createResource(uri);
		
		try {
			bigResource.load(Map.of());
		} catch (IOException e) {
			e.printStackTrace();
		}
		
		var pack 	= (EPackage) bigResource.getContents().get(0);
		var eclass 	= (EClass) pack.getEClassifiers().get(0);
		var attr 	= (EAttribute) eclass.getEStructuralFeatures().get(0);

		eclass.getEStructuralFeatures().clear();
		pack.getEClassifiers().clear();
		
		var classNamePrefix = eclass.getName().replaceFirst("\\d+$", "");
		var attrNamePrefix 	= attr.getName().replaceFirst("\\d+$", "");
		
		for (var i = 1; i <= NUMBER_ATTRIBUTES; i++) {
			var nextAttr = EcoreUtil.copy(attr);
			nextAttr.setName(attrNamePrefix + i);
			eclass.getEStructuralFeatures().add(nextAttr);
		}

		for (var i = 1; i <= NUMBER_CLASSES; i++) {
			var nextEclass = EcoreUtil.copy(eclass);
			nextEclass.setName(classNamePrefix + i);
			pack.getEClassifiers().add(nextEclass);
		}
		
		try {
			bigResource.save(Map.of());
		} catch (IOException e) {
			e.printStackTrace();
		}
		
	}
}

[mr-cheddar]

Thanks for the links 🤙. I think I will find a solution and will report later. JET templates are not that difficult.

Here are some snippets from the EMF book for documentation purposes (in case somebody is curious about the properties):

[merks]

You might consider to contribute the changes back to the framework. I wonder if factoring out the body of each switch case into a private method would be sufficient to reduce the doSwitch method to a reasonable size. The SwitchClass.javajet it quite a simple template...