=Paper=
{{Paper
|id=None
|storemode=property
|title=Model-Driven Modernisation of Java Programs with JaMoPP
|pdfUrl=https://ceur-ws.org/Vol-708/mdsm2011-heidenreich-et-al-11-jamopp.pdf
|volume=Vol-708
}}
==Model-Driven Modernisation of Java Programs with JaMoPP==
https://ceur-ws.org/Vol-708/mdsm2011-heidenreich-et-al-11-jamopp.pdf
Model-driven Modernisation of Java Programs with JaMoPP
Florian Heidenreich, Jendrik Johannes, Jan Reimann, Mirko Seifert,
Christian Wende, Christian Werner, Claas Wilke, Uwe Assmann
Technische Universität Dresden
D-01062, Dresden, Germany
Email: firstname.lastname@tu-dresden.de
Abstract—The history of all programming languages exposes is needed. In earlier work, we presented JaMoPP [2], [3]—
the introduction of new language features. In the case of Java— the Java Model Printer and Parser—a tool that entails a
a widespread general purpose language—multiple language complete metamodel for Java and tooling to convert Java
extensions were applied over the last years and new ones are
planned for the future. Often, such language extensions provide source code to Eclipse Modeling Framework (EMF) [4]
means to replace complex constructs with more compact ones. models and vice versa. Therefore, JaMoPP enables arbitrary
To benefit from new language extensions for large bodies of EMF-based tools to work on Java programs.
existing source code, a technique is required that performs the In this paper, we show how JaMoPP and a standardised
modernisation of existing source code automatically. model transformation language can be combined to migrate
In this paper we demonstrate, how Java programs can be
automatically migrated to new versions of the Java language. Java code to a new version of the Java language. We present
Using JaMoPP, a tool that can create models from Java source two concrete migration examples. First, existing for loops
code, we enable the application of model transformations to are transformed to the for-each style that was introduced in
perform model-driven modernisation of Java programs. Our Java 5. Second, the conversion of anonymous inner classes
approach is evaluated by applying two concrete transforma- to closures, which are planned for the Java 8 release, is
tions to large open source projects. First, we migrate classical
for loops to the new for-each style (introduced in Java 5). performed. We apply the two transformations to a set of large
Second, we convert anonymous classes to closures (planned for open source Java projects. The results of this transformation
Java 8). Furthermore, we discuss how tracing transformations can be used to quantify the impact of new language features.
allows to quantify the impact of planned extensions. The paper is structured as follows. After giving a brief
overview on JaMoPP in Sect. II, we discuss the transforma-
I. I NTRODUCTION tions for the two migration examples in Sect. III. The result
Programming languages evolve over time: new features of performing the transformations of larger bodies of source
are added and occasionally old ones are removed. A promi- code can be found in Sect. IV. We compare our work with
nent example of a language that undergoes such an evolution related approaches in Sect. V, and conclude in Sect. VI.
is Java. For example, generics were introduced in Java 5.
II. JA M O PP—B RIEF OVERVIEW
All changes—with a few exceptions—that were intro-
duced to Java, preserved backward compatibility. Programs In MDSD, many generic modelling tools exist that can
written in older versions do still compile and run with new be used in combination with arbitrary languages. This is
versions. Still, old programs could be updated using new possible because the tools can be configured with metamo-
language features, assuming this improves code readability dels. A metamodel describes the concepts of a language; also
and therewith maintainability. For small programs, old code referred to as the abstract syntax of a language. To exchange
fragments can be replaced manually, but for large code bases metamodels between tools, the OMG has standardised the
automatic code modernisation transformations are required. metamodelling languages Meta-Object Facility (MOF) and
Source code transformations are known for quite a while Essential Meta-Object Facility (EMOF)2 . A widely used
and specialised tools exist to perform this task (cf. Sect. V). implementation of EMOF is Ecore as part of EMF. To use
However, with the advent of Model-Driven Software Devel- a generic modelling tool that supports Ecore with a certain
opment (MDSD) [1], standardised transformation languages language, a metamodel of that language needs to be provided
(e.g., Query View Transformation (QVT)1 ) became avail- together with tooling to parse (and print) sentences written
able. If one could use these languages for code transforma- in the language’s concrete syntax (e.g., a Java program) into
tion, the need for specialised languages would vanish. typed graphs that conform to the metamodel.
To apply a model transformation language to source With JaMoPP, we provide such an Ecore metamodel
code, a model of the respective code is required. Also, a and the tooling to parse and print source code for the
metamodel of the language that is subject to transformation Java language (currently supporting Java 5). This allows
1 http://www.omg.org/spec/QVT/ 2 http://www.omg.org/spec/MOF/2.0
developers to apply generic modelling tools on Java source 1 mapping t r a n s f o r m F o r L o o p T o F o r e a c h L o o p
2 ( f o r L o o p : JAVA : : s t a t e m e n t s : : ForLoop )
code and hence to use the same tools to work with models 3 : JAVA : : s t a t e m e n t s : : ForEachLoop
(e.g., UML models) and source code. An example of such 4 when {
a tool, which we show in the next section, is the QVT 5 f o r L o o p . c h e c k L o o p I n i t ( ) and
6 f o r L o o p . c h e c k L o o p C o n d i t i o n ( ) and
transformation language. 7 f o r L o o p . c h e c k L o o p C o u n t i n g E x p r e s s i o n ( ) and
Important properties of JaMoPP are: (1) JaMoPP supports 8 forLoop . checkLoopStatements ( )
both parsing and printing Java code which allows modelling 9 }{
10 var l i s t T y p e : JAVA : : t y p e s : : T y p e R e f e r e n c e
tools (e.g., model transformation engines) to both read and 11 := g e t I t e r a t e d C o l l e c t i o n T y p e ( c o u n t e r I d e n t i f i e r ) ;
modify Java source code. This conversion preserves the 12 var l o o p P a r a m e t e r
layout of Java source code. (2) In addition to parsing, 13 : = o b j e c t JAVA : : p a r a m e t e r s : : O r d i n a r y P a r a m e t e r {
14 name : = ” e l e m e n t ” ;
JaMoPP performs name and type analysis of the source code 15 typeReference := l i s t T y p e };
and establishes links (e.g., between the usage and definition 16 r e s u l t . next := loopParameter ;
of a Java class). These links can be exploited by modelling 17 r e s u l t . s t a t e m e n t :=
18 map r e p l a c e C o l l e c t i o n A c c e s s o r S t a t e m e n t s (
tools to ensure correctness of static semantics properties of 19 forLoop , l o o p P a r a m e t e r ) ;
the Java source files they generate or modify. (3) JaMoPP 20 }
itself was developed using our modelling tool EMFText [5]. Listing 1. QVT Transformation to replace for loops with for-each loops.
There, the concrete syntax of Java is defined in an EBNF-
A. Example of Model-Driven Modernisation of For Loops
like syntax definition. Based on the metamodel and this
definition, the parser and printer tooling is generated. This Listing 1 shows a mapping taken from the transfor-
allows us to extend JaMoPP by extending the metamodel mation of for loops to for-each loops. An example of
and the syntax definition without the need to modify code. the expected replacement and a description of the loop
With this, JaMoPP can co-evolve with future Java versions elements used in the transformation is given in Fig. 1.
and can, in particular, be used to prototype and experiment The mapping consists of a when-clause (lines 4-9) and
with new features. An example of this is closure support, a mapping body (lines 10-20). The when-clause defines
which is used in Sect. IV. a number of preconditions that need to be satisfied by a
JaMoPP has been tested with a large body of source code given for loop to be replaced. For instance, that the init-
from open-source Java projects through which stability and statement initialises the loop counter variable with
support for all Java 5 language features is assured (see [2] 0, that the loop condition ensures iteration among all
for details). Initially [2], we focused on using JaMoPP for collection elements, or that the counting expression
forward engineering to generate and compose Java code. always increases the loop counter variable by 1.
In [3] we presented how JaMoPP is used for reverse engi- Furthermore, the loop statements are not allowed to
neering. In the next section, we demonstrate how JaMoPP refer to the counter variable aside from accessing
is used in combination with QVT for modernisation, which the collection for the next element. If all preconditions are
is a combination of reverse and forward engineering. satisfied we calculate the generic type of the collection
that is iterated (lines 10-11) and create an iteration
parameter for the for-each loop that is initialised with
III. M ODEL - DRIVEN S OURCE C ODE T RANSFORMATION
this type (line 12-15). Finally, the new for-each loop is
In this section we first exemplify Model-Driven Moderni- initialised with this parameter and its body is filled with the
sation using our first migration example—the transformation statements of the original for loop, where all statements for
of for loops to the for-each loops. Afterwards we discuss collection access are replaced with references
the benefits and challenges we experienced in applying to the iteration parameter of the for-each loop.
model transformations for source code modernisation in
B. Applicability of QVT for Model-Driven Modernisation
both migration examples (for-each loops and closures). The
complete transformation scripts can be found online3 . For the specification of both transformation scripts we
To implement our modernisation transformations we used used a set of tools provided by the M2M project for
QVT-Operational provided by the Eclipse M2M project4 . QVT-Operational. The included editor provided advanced
We consider the declarative language QVT-Operational a editing features like syntax highlighting, code navigation,
pragmatic choice for the unidirectional transformations typ- and code completion. Especially code completion helped a
ically required for source-code modernisation. In contrast, lot in writing expressions that traverse and analyse Java
its declarative counterparts (QVT-Relations, QVT-Core) are models. A second tool that helped a lot in developing
more suitable for bi-directional transformation. transformations was the QVT debugger. It allows the step-
wise evaluation of transformation execution and was indis-
3 http://jamopp.org/index.php/JaMoPP Applications Modernisation/ pensable to understand and fix problems in our complex
4 http://www.eclipse.org/m2m/ transformation scripts. Third, the QVT interpreter generates
counter variable collection condition iteration parameter
init
counting reference to
loop statements collection access expression iteration parameter
Figure 1. Example of for loop replacement explaining the elements of for- and for-each loops.
tracing information for each execution of the transformation. compilation units. This includes all types referenced by this
The trace records all mappings applied and enabled the unit, but excludes other, unrelated parts of the source code.
quantitative analysis of our examples. We think that the We used a machine with a Dual Core AMD Opteron running
reusability and maturity of these generic tools provide some at 2.4 GHz with 4 GB RAM. We used only one core of the
good arguments for applying a standardised transformation machine to avoid problems with Eclipse plug-ins that are
language. not thread-safe.
A benefit of model-driven modernisation was the graph-
Framework Files For loops Closures
structure of models, which, compared to tree-structures often min repl./occur. min repl./occur.
provided by code parsing tools, allow for more convenient AndroMDA 3.3 698 3 4/959 8 8/201
navigation and analysis of references between declarations Apache Ant 1.8.1 829 5 24/1028 21 12/99
Comns. Math 1.2 395 1 25/845 5 0/25
and uses of code elements (e.g., variables). For example, this Tomcat 6.0.18 1127 4 65/1437 15 52/125
eased the specification of the preconditions for the for loop GWT 1.5.3 1850 5 29/1044 23 26/670
migration that searches the method body for statements that JBoss 5.0.0.GA 6414 16 472/2744 70 197/591
Mantissa 7.2 242 1 7/652 3 18/29
use the counter variable declared in the loop header.
Spring 3.0.0.M1 3096 8 82/680 43 31/1403
In both examples it is not trivial to come up with an Struts 2.1.6 1035 3 7/130 13 8/158
exhaustive set of patterns that identify source code that can XercesJ 2.9.1 716 3 21/1111 12 62/94
be modernised. We consider this a challenge for source code 16402 49 736/10630 213 414/3395
modernisation in general. However, we also learned that Figure 2. Transformation time and ratio of found and replaced elements.
some idioms (like the for loop presented in Fig. 1) are quite The results of our measurements are shown in Fig. 2.
common and occurred in all Java projects we investigated, From these numbers one can derive that the pure average
as can be seen in the next section. transformation time per source file is 0.2 seconds (for-each
Some drawback of using model transformations for code loops) and 0.8 seconds (closures). These values can be
modernisation was the focus on abstract syntax, i.e., the obtained by dividing the total time (given in minutes in
language metamodel. It required a good knowledge of the columns 3 and 5) by the number of total source files. In
JaMoPP metamodel and some training to represent patterns addition to the transformation time one must also take into
of source code in abstract syntax. On the other hand, the account the time needed to load the input models. This can
strict structure of an explicit metamodel was beneficial to take up to a few minutes for very complex source files, but is
ensure the well-formedness of the produced source code. usually done within few seconds. For a migration task, which
is performed once for every new release of a programming
IV. E VALUATION language, this renders the approach still feasible.
To evaluate the performance of our source code mod-
B. Quantification of Language Extensions
ernisation approach, we applied the transformations from
Sect. III to a set of Java frameworks available to the public. To quantify the impact of a planned language extension,
Our goal was to answer the following questions: First, one can count the number of replaceable language con-
we wanted to know whether a general purpose modelling structs. This is usually only a subset of all cases where a new
environment like EMF is scalable enough to handle such a language construct is applicable. Some potential applications
large set of models. Second, we were curious how many of a language construct may simply not be detected, because
resources are required to perform a transformation of this developers used structures not covered in the transformation
scale with QVT—a generic model transformation language. script.
To answer these questions, we transformed 16.402 Java files Nonetheless, the number of places in existing source code
from 10 open source projects. where a new language construct can be applied, does at least
give some indication about its impact. The ratio for loops
A. Performance that can be replaced by for-each loops to all for loops found,
To evaluate the transformation performance, we measured and the ratio of anonymous inner classes that are replaceable
the time needed to perform the transformations on individual by closures to all inner classes found is shown in Fig. 2.
On average, 6.9% of all for loops were transformed to and 12.2% of all anonymous classes were considered as
the for-each style. The percentage of anonymous classes candidates for transformation). So far we only used our own
that were replaced by closures was 12.2%. Certainly, these judgement based on our experience with Java to determine
numbers can be increased if more patterns are covered by the the semantic correctness of the transformation rules. In fu-
transformation scripts. However, given the very restrictive ture we plan to automatically validate correctness by running
scripts which we used, the numbers are quite high. Thus, the test suites of the open-source projects on the modernised
one can reason that actual benefit can be gained by using code. Further, we did not yet compare the effort of writing
automatic transformations here and that both language ex- QVT transformations for Java with alternatives such as
tensions are useful additions to the Java language. using Java-specific source code transformation tools or other
model transformation languages. Doing this comparison by
V. R ELATED W ORK
implementing the two modernisation transformations with
There exists a large amount of work and tools for source different languages and tools is subject to future work.
code transformation.5 One prominent approach is Strate-
go/XT [6], a tool set for strategic rewriting of source code. ACKNOWLEDGMENT
While Stratego/XT and other approaches are proved to be This research is co-funded by the European Commission
useful and applicable in academic and industrial projects, within the projects MODELPLEX #034081 and MOST
they do not provide a standardised transformation language. #216691, by the German Ministry of Education and Re-
With JaMoPP one can transform source code to a standard- search (BMBF) within the projects feasiPLe and SuReal; by
ised intermediate representation (i.e., EMF-based models) the German Research Foundation (DFG) within the project
where we apply a standardised transformation language HyperAdapt and by the European Social Fund and Federal
(i.e., QVT). This can be generalised to other programming State of Saxony within the project ZESSY #080951806.
languages and other transformation languages.
MoDisco [7] aims at discovering models from legacy R EFERENCES
applications. It handles Java code as well as other arte- [1] M. Völter, T. Stahl, J. Bettin, A. Haase, and S. Helsen, Model-
facts (e.g., configuration files). Based on the Eclipse JDT Driven Software Development. John Wiley & Sons, 2006.
parser, MoDisco creates models from source code files. The
[2] F. Heidenreich, J. Johannes, M. Seifert, and C. Wende, “Clos-
metamodel for these models is defined in Ecore similar ing the Gap between Modelling and Java,” in Proc. of 2nd Int’l
to JaMoPP. Thus, transformations can be specified using Conf. on Software Language Engineering (SLE’09), ser. LNCS,
existing languages (e.g., QVT). However, MoDisco does not vol. 5969. Springer, Mar. 2010, pp. 374–383.
preserve the layout of the source code when printing back
transformed models back to their original representation [3] ——, “Construct to Reconstruct—Reverse Engineering Java
Code with JaMoPP,” in Proc. of Int’l Workshop on Reverse
(i.e., Java source code). Approaches for metamodel evolution Engineering Models from Software Artifacts (R.E.M. 2009),
(e.g., [8]) are inherently limited to the model level and do Oct. 2009.
not allow to print models after performing evolution steps.
Architecture-driven Modernisation (ADM)6 of the OMG [4] D. Steinberg, F. Budinsky, M. Paternostro, and E. Merks,
goes beyond what is presented in this paper by applying Eclipse Modeling Framework (2nd Edition). Pearson Edu-
cation, 2009.
modernisation efforts on all artefacts involved in the software
development process (e.g., source code, database definitions, [5] F. Heidenreich, J. Johannes, S. Karol, M. Seifert, and
configuration files, ...). However, strategies that are built C. Wende, “Derivation and Refinement of Textual Syntax for
on top of existing OMG standards (e.g., similar to the Models,” in Proc. of ECMDA-FA’09, ser. LNCS, vol. 5562.
combination of EMOF and QVT in our approach) can fit Springer, Jun. 2009, pp. 114–129.
nicely in the overall goal of ADM. [6] E. Visser, “Program transformation with Stratego/XT: Rules,
strategies, tools, and systems in StrategoXT-0.9,” in Domain-
VI. C ONCLUSION & F UTURE W ORK
Specific Program Generation, ser. LNCS, C. Lengauer, D. Ba-
In this paper, we implemented and evaluated two exam- tory, C. Consel, and M. Odersky, Eds. Spinger, Jun. 2004,
ples of Java modernisation to show that JaMoPP in combi- vol. 3016, pp. 216–238.
nation with the standardised model transformation language
[7] H. Bruneliere, J. Cabot, F. Jouault, and F. Madiot, “MoDisco: A
QVT can be used for Model-Driven Modernisation of Java Generic and Extensible Framework for Model Driven Reverse
programs. In applying the transformations on a set of open- Engineering,” in Proc. of ASE’10. ACM, 2010, pp. 173–174.
source projects we experienced that the transformations
can be performed in acceptable time and transformed a [8] M. Herrmannsdoerfer, S. Benz, and E. Juergens, “COPE -
reasonable part of the code (on average, 6.9% of all for loops Automating Coupled Evolution of Metamodels and Models,”
in Proc. of ECOOP’09, ser. LNCS, S. Drossopoulou, Ed., vol.
5 http://www.program-transformation.org/ provides an overview. 5653. Springer, 2009, pp. 52–76.
6 http://adm.omg.org/