-The history of all programming languages exposes the introduction of new language features. In the case of Javaa widespread general purpose language-multiple language extensions were applied over the last years and new ones are planned for the future. Often, such language extensions provide means to replace complex constructs with more compact ones. To benefit from new language extensions for large bodies of existing source code, a technique is required that performs the modernisation of existing source code automatically. In this paper we demonstrate, how Java programs can be automatically migrated to new versions of the Java language. Using JaMoPP, a tool that can create models from Java source code, we enable the application of model transformations to perform model-driven modernisation of Java programs. Our approach is evaluated by applying two concrete transformations to large open source projects. First, we migrate classical for loops to the new for-each style (introduced in Java 5). Second, we convert anonymous classes to closures (planned for Java 8). Furthermore, we discuss how tracing transformations allows to quantify the impact of planned extensions.
Programming languages evolve over time: new features are added and occasionally old ones are removed. A prominent example of a language that undergoes such an evolution is Java. For example, generics were introduced in Java 5.
All changes—with a few exceptions—that were introduced to Java, preserved backward compatibility. Programs written in older versions do still compile and run with new versions. Still, old programs could be updated using new language features, assuming this improves code readability and therewith maintainability. For small programs, old code fragments can be replaced manually, but for large code bases automatic code modernisation transformations are required.
Source code transformations are known for quite a while
and specialised tools exist to perform this task (cf. Sect. V).
However, with the advent of Model-Driven Software
Development (MDSD) [
To apply a model transformation language to source
code, a model of the respective code is required. Also, a
metamodel of the language that is subject to transformation
is needed. In earlier work, we presented JaMoPP [
In this paper, we show how JaMoPP and a standardised model transformation language can be combined to migrate Java code to a new version of the Java language. We present two concrete migration examples. First, existing for loops are transformed to the for-each style that was introduced in Java 5. Second, the conversion of anonymous inner classes to closures, which are planned for the Java 8 release, is performed. We apply the two transformations to a set of large open source Java projects. The results of this transformation can be used to quantify the impact of new language features.
The paper is structured as follows. After giving a brief overview on JaMoPP in Sect. II, we discuss the transformations for the two migration examples in Sect. III. The result of performing the transformations of larger bodies of source code can be found in Sect. IV. We compare our work with related approaches in Sect. V, and conclude in Sect. VI.
In MDSD, many generic modelling tools exist that can be used in combination with arbitrary languages. This is possible because the tools can be configured with metamodels. A metamodel describes the concepts of a language; also referred to as the abstract syntax of a language. To exchange metamodels between tools, the OMG has standardised the metamodelling languages Meta-Object Facility (MOF) and Essential Meta-Object Facility (EMOF)2. A widely used implementation of EMOF is Ecore as part of EMF. To use a generic modelling tool that supports Ecore with a certain language, a metamodel of that language needs to be provided together with tooling to parse (and print) sentences written in the language’s concrete syntax (e.g., a Java program) into typed graphs that conform to the metamodel.
With JaMoPP, we provide such an Ecore metamodel and the tooling to parse and print source code for the Java language (currently supporting Java 5). This allows 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 code and hence to use the same tools to work with models 32 (: f oJAr VLAoo:p: s t: a tJAemVAe n::t ss t:a: tFeomrEeancthsL: o:oFporLoop ) (e.g., UML models) and source code. An example of such 4 when f 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 transformation language. 67 ff oo rr LL oo oo pp .. cc hh ee cc kkLLooooppCCoonudnittiinognE(x)p raensds i o n ( ) and
Important properties of JaMoPP are: (1) JaMoPP supports 8 f o r L o o p . c h e c k L o o p S t a t e m e n t s ( ) both parsing and printing Java code which allows modelling 190 tools (e.g., model transformation engines) to both read and 11 modify Java source code. This conversion preserves the 12 layout of Java source code. (2) In addition to parsing, 13
14
JaMoPP performs name and type analysis of the source code 15
and establishes links (e.g., between the usage and definition 16
of a Java class). These links can be exploited by modelling 1187
tools to ensure correctness of static semantics properties of 19
the Java source files they generate or modify. (3) JaMoPP 20 g
itself was developed using our modelling tool EMFText [
With this, JaMoPP can co-evolve with future Java versions and can, in particular, be used to prototype and experiment with new features. An example of this is closure support, which is used in Sect. IV.
JaMoPP has been tested with a large body of source code
from open-source Java projects through which stability and
support for all Java 5 language features is assured (see [
In [
Listing 1 shows a mapping taken from the transformation of for loops to for-each loops. An example of the expected replacement and a description of the loop elements used in the transformation is given in Fig. 1.
The mapping consists of a when-clause (lines 4-9) and a mapping body (lines 10-20). The when-clause defines a number of preconditions that need to be satisfied by a given for loop to be replaced. For instance, that the initstatement initialises the loop counter variable with 0, that the loop condition ensures iteration among all collection elements, or that the counting expression always increases the loop counter variable by 1.
Furthermore, the loop statements are not allowed to refer to the counter variable aside from accessing the collection for the next element. If all preconditions are 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 this type (line 12-15). Finally, the new for-each loop is initialised with this parameter and its body is filled with the statements of the original for loop, where all statements for collection access are replaced with references to the iteration parameter of the for-each loop.
gf 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
: = 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 ) ; var l o o p P a r a m e t e r : = 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 f name : = ” e l e m e n t ” ; t y p e R e f e r e n c e : = l i s t T y p e g ; r e s u l t . n e x t : = l o o p P a r a m e t e r ; r e s u l t . s t a t e m e n t : = 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 ( forLoop , l o o p P a r a m e t e r ) ; III. MODEL-DRIVEN SOURCE CODE TRANSFORMATION
In this section we first exemplify Model-Driven Modernisation using our first migration example—the transformation of for loops to the for-each loops. Afterwards we discuss the benefits and challenges we experienced in applying model transformations for source code modernisation in both migration examples (for-each loops and closures). The complete transformation scripts can be found online3.
To implement our modernisation transformations we used QVT-Operational provided by the Eclipse M2M project4.
We consider the declarative language QVT-Operational a pragmatic choice for the unidirectional transformations typically required for source-code modernisation. In contrast, its declarative counterparts (QVT-Relations, QVT-Core) are more suitable for bi-directional transformation.
3http://jamopp.org/index.php/JaMoPP Applications Modernisation/ 4http://www.eclipse.org/m2m/ B. Applicability of QVT for Model-Driven Modernisation
For the specification of both transformation scripts we used a set of tools provided by the M2M project for QVT-Operational. The included editor provided advanced editing features like syntax highlighting, code navigation, and code completion. Especially code completion helped a lot in writing expressions that traverse and analyse Java models. A second tool that helped a lot in developing transformations was the QVT debugger. It allows the stepwise evaluation of transformation execution and was indispensable to understand and fix problems in our complex transformation scripts. Third, the QVT interpreter generates counter variable collection condition iteration parameter init loop statements collection access counting expression
reference to iteration parameter tracing information for each execution of the transformation.
The trace records all mappings applied and enabled the quantitative analysis of our examples. We think that the reusability and maturity of these generic tools provide some good arguments for applying a standardised transformation language.
A benefit of model-driven modernisation was the graphstructure of models, which, compared to tree-structures often provided by code parsing tools, allow for more convenient navigation and analysis of references between declarations and uses of code elements (e.g., variables). For example, this eased the specification of the preconditions for the for loop migration that searches the method body for statements that use the counter variable declared in the loop header.
In both examples it is not trivial to come up with an exhaustive set of patterns that identify source code that can be modernised. We consider this a challenge for source code modernisation in general. However, we also learned that some idioms (like the for loop presented in Fig. 1) are quite common and occurred in all Java projects we investigated, as can be seen in the next section.
Some drawback of using model transformations for code modernisation was the focus on abstract syntax, i.e., the language metamodel. It required a good knowledge of the JaMoPP metamodel and some training to represent patterns of source code in abstract syntax. On the other hand, the strict structure of an explicit metamodel was beneficial to ensure the well-formedness of the produced source code.
IV. EVALUATION
To evaluate the performance of our source code modernisation approach, we applied the transformations from Sect. III to a set of Java frameworks available to the public.
Our goal was to answer the following questions: First, we wanted to know whether a general purpose modelling environment like EMF is scalable enough to handle such a large set of models. Second, we were curious how many resources are required to perform a transformation of this scale with QVT—a generic model transformation language.
To answer these questions, we transformed 16.402 Java files from 10 open source projects.
To evaluate the transformation performance, we measured the time needed to perform the transformations on individual compilation units. This includes all types referenced by this unit, but excludes other, unrelated parts of the source code. We used a machine with a Dual Core AMD Opteron running at 2.4 GHz with 4 GB RAM. We used only one core of the machine to avoid problems with Eclipse plug-ins that are not thread-safe.
Framework AndroMDA 3.3 Apache Ant 1.8.1 Comns. Math 1.2 Tomcat 6.0.18 GWT 1.5.3 JBoss 5.0.0.GA Mantissa 7.2 Spring 3.0.0.M1 Struts 2.1.6 XercesJ 2.9.1
Files
To quantify the impact of a planned language extension, one can count the number of replaceable language constructs. This is usually only a subset of all cases where a new language construct is applicable. Some potential applications of a language construct may simply not be detected, because developers used structures not covered in the transformation script.
Nonetheless, the number of places in existing source code where a new language construct can be applied, does at least give some indication about its impact. The ratio for loops that can be replaced by for-each loops to all for loops found, and the ratio of anonymous inner classes that are replaceable by closures to all inner classes found is shown in Fig. 2.
On average, 6.9% of all for loops were transformed to the for-each style. The percentage of anonymous classes that were replaced by closures was 12.2%. Certainly, these numbers can be increased if more patterns are covered by the transformation scripts. However, given the very restrictive scripts which we used, the numbers are quite high. Thus, one can reason that actual benefit can be gained by using automatic transformations here and that both language extensions are useful additions to the Java language.
V. RELATED WORK
There exists a large amount of work and tools for source
code transformation.5 One prominent approach is
Stratego/XT [
MoDisco [
Architecture-driven Modernisation (ADM)6 of the OMG goes beyond what is presented in this paper by applying modernisation efforts on all artefacts involved in the software development process (e.g., source code, database definitions, configuration files, ...). However, strategies that are built on top of existing OMG standards (e.g., similar to the combination of EMOF and QVT in our approach) can fit nicely in the overall goal of ADM.
In this paper, we implemented and evaluated two examples of Java modernisation to show that JaMoPP in combination with the standardised model transformation language QVT can be used for Model-Driven Modernisation of Java programs. In applying the transformations on a set of opensource projects we experienced that the transformations can be performed in acceptable time and transformed a reasonable part of the code (on average, 6.9% of all for loops 5http://www.program-transformation.org/ provides an overview. 6http://adm.omg.org/ and 12.2% of all anonymous classes were considered as candidates for transformation). So far we only used our own judgement based on our experience with Java to determine the semantic correctness of the transformation rules. In future we plan to automatically validate correctness by running the test suites of the open-source projects on the modernised code. Further, we did not yet compare the effort of writing QVT transformations for Java with alternatives such as using Java-specific source code transformation tools or other model transformation languages. Doing this comparison by implementing the two modernisation transformations with different languages and tools is subject to future work.
This research is co-funded by the European Commission within the projects MODELPLEX #034081 and MOST #216691, by the German Ministry of Education and Research (BMBF) within the projects feasiPLe and SuReal; by the German Research Foundation (DFG) within the project HyperAdapt and by the European Social Fund and Federal State of Saxony within the project ZESSY #080951806.