Community
Participate
Working Groups
Created attachment 251149 [details] Java-serialized grammar Bug 460677 identified an incompatible change to Xcore.ecore that resulted in a *.xtextbin created by Xtext 2.8 giving an ArrayIndexOutOfBoundException when read on Xtext 2.3.1. The problem is that binary resources use efficient binary featureIds allocated according to the *.ecore. So long as the *.ecore is unchanged; no problem. However we expect to be able to make 'safe' upgrades to models as occurred to Xcore.ecore in 2014. Any change to Xcore.ecore causes a backward incompatibility, which Xtext supports, e.g. an Xtext 2.8 created editor might fail on an Xtext 2.9 run-time. This is in addition to the forward incompatibility reported in Bug 460677, not supported by Xtext. One possible solution is to revert to *.xmi grammars, but this has disappointing startup performance. A better solution adopted by 10 OCL and QVTd grammars is to serialize the *.xtextbin as a *GrammarResource.java so that the grammar is constructed by direct code without any need for model loading, proxy resolution. The EMF accesses can be fairly direct so an improved load-time can be expected. Since the grammar is statically constructed, a single static instance can be shared by all uses. The size of the *.class file is two to four times the size of the *.xtextbin. The corresponding *.java file is readable (and debuggable if necessary). Attached is an XtextGrammarResource.java that could be adopted in principle just be changing the GrammarProvider binding to use XtextGrammarResource.GrammarProvider.class. In practice the AbstractGrammarResource base class needs to be copied from OCL. The automated tooling for generating the *GrammarResources is appended to the OCL/QVTd editor creation MWE2 scripts. Xtext Fragment experts can no doubt incorporate it directly in the GrammarAccessFragment.
