DevBooststLogotudLogorewerseLogo modelplexLogo
crimsonBG
JaMoPP
Bridging the gap between models and source code.

Java Extension to Separate Generated and Hand-Written Code

Return to Main JaMoPP Applications Page

Resources

Description

To demonstrate and experiment with new language concepts, Java is often extended with new features. These features are implemented in prototypes that can often only treat subsets of Java due to a lack of language engineering tool support. Existing tools, like editors, can no longer be used when unaware of the extension.

In MDSD, tools for metamodelling and agile language development exist that are aware of evolution and change of languages, which makes it considerably easier to perform language extension while preserving tool support. The GMF definitions, for instance, can be easily adjusted if changes to the Java metamodel are made---and the GMF editor can be regenerated. Same applies to EMFText's CS-specifications, which have an import mechanism to extend a text syntax along with a metamodel.

The scenario we examine in this section is separation of generated code skeletons (as produced by an ATL transformation) from the list of statements of a method body directly defined in Java. Usually these can not be separated into single artefacts in Java, because a list of statements on its own is not a compilable unit. Furthermore, it would be helpful, if a transformation to Java can indicate where additional code is required when the information for generating it is missing. Java does also not provide a specific construct for that.

Here, we extend Java with the two features mentioned above and utilise the Reuseware Composition Framework to define a preprocessor that composes models of the extended Java language into plain Java. To do so, the Java metamodel is extended by defining a new package reuse with the classes 1) StatementUnit, which is a subclass of JavaRoot and has a reference statements of type Statement, and 2) StatementVariationPoint, which is a subclass of Statement. Both are also NamedElements. This extension can be done without altering the original Java metamodel by using the import feature of Ecore.

The text syntax is extended in a similar manner as shown below. In Line 1, the Java metamodel http://... and its text syntax java are identified for import. In Lines 2 and 3 two additional rules that give the text syntax for the new constructs are specified. EMFText takes all the rules of the imported syntax into account when generating printer and parser. Therefore, the new rules are woven into the existing syntax: StatementUnit can be used as alternative for other JavaRoots (e.g., CompilationUnit) and StatementVariationPoint as alternative for other Statements.

 IMPORTS { java : <http://www.emftext.org/java> WITH SYNTAX java }
 RULES {
   StatementUnit ::=            "statements" name[] "{" statements* "}" ;
   StatementVariationPoint ::=  "<" "<" name[] ">" ">"  ";" ;
 }

Figure 1 shows a usage of the extended Java. The ATL transformation can be extended to produce a StatementVariationPoint for empty methods (lower left of Figure 1), or wherever else information is missing. EMFText's editor remains working for the extended Java and can be used to define statement lists stand alone (lower right of Figure 1). These can be composed with the generated code by defining composition programs in Reuseware (top of Figure 1)–thus keeping a clean separation between generated and hand-written (or hand-modeled) code.

Figure 1. Screenshot of using the extended Java with Reuseware

This section showed how a Java extension can be easily realised using MDSD technologies with JaMoPP. Only two additional metaclasses and 5 lines of text syntax specification were needed. Therefore, JaMoPP enables the definition of custom extensions for Java tailored to any specific MDSD process.