Specifying and Implementing Refactorings
DOI: 10.1145/1869459.1869485 Conference: Proceedings of the 25th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications, OOPSLA 2010, October 17-21, 2010, Reno/Tahoe, Nevada, USA
Modern IDEs for object-oriented languages like Java provide support for a basic set of simple automated refactorings whose behaviour is easy to describe intuitively. It is, however, surprisingly difficult to specify their behaviour in detail. In particular, the popular precondition-based approach tends to produce somewhat unwieldy descriptions if advanced features of the object language are taken into account. This has resulted in refactoring implementations that are complex, hard to understand, and even harder to maintain, yet these implementations themselves are the only precise "specification" of many refactorings. We have in past work advocated a different approach based on several complementary notions of dependencies that guide the implementation, and on the concept of microrefactorings that structure it. We show in this work that these concepts are powerful enough to provide high-level specifications of many of the refactorings implemented in Eclipse. These specifications are precise enough to serve as the basis of a clean-room reimplementation of these refactorings that is very compact, yet matches Eclipse's for features and outperforms it in terms of correctness.
Available from: Marco Tulio Valente
- "Currently, JMove relies on the preconditions defined by the Move Method automatic refactoring supported by the Eclipse IDE. However, it is well-known that Eclipse implements weak preconditions for some refactorings   . For this reason, we strengthened the Eclipse preconditions by supporting the following five preconditions originally proposed by the JDeodorant tool . "
20th Working Conference on Reverse Engineering (WCRE); 01/2013
Available from: Coen De Roover
- "While it would be possible to augment the refactoring preconditions with the annotation behavior specifications, we have decided instead to implement the annotation behavior preservation as post-conditions. The use of post-condition dependency checking in refactoring has already been proposed  to simplify the implementations of refactorings, although it has not been applied to the problem of annotated code. Since we express the problem of behavior preservation of annotated code as a dependency preservation problem, a postcondition that checks whether the dependencies were maintained by the refactoring transformation is more natural than trying to a priori predict whether the refactoring will affect said dependencies. "
[Show abstract] [Hide abstract]
ABSTRACT: Current-day programming languages include constructs to embed meta-data in a program's source code in the form of annotations. More than mere documentation, these annotations are used in modern frameworks to map source-level entities to domain-specific ones. A common example being the Hibernate Object-Relational Mapping framework that relies on annotations to declare persistence configurations. While the presence of annotations extends the base semantics of the language, it also imposes restrictions on the annotated program. In this paper we consider the manner in which annotations affect automated refactorings, and in particular how they break their behavior preservation. As refactorings, during their condition checking phase, ignore the annotation's restrictions they can no longer guarantee the preservation of the domain-specific mappings. To address this problem, we propose to make the restrictions of the annotations explicit, and use them to steer the refactoring process. A prototype extension of the Eclipse IDE's refactoring engine is used to demonstrate our approach on three annotation libraries: Java Persistence API, AspectJ5 and Simple XML serialization.
Proceedings of the 2012 IEEE International Conference on Software Maintenance (ICSM); 09/2012
Available from: users.ece.utexas.edu
- "Refactoring Edit Validation. Schaeffer et al. validate refactoring edits by comparing data and control dependences between two program versions . As opposed to validating refactoring edits, Daniel et al. focus on testing refactoring engines by systematically generating input programs for refactoring transformations . "
[Show abstract] [Hide abstract]
ABSTRACT: It is widely believed that refactoring improves software quality and developer's productivity by making it easier to maintain and understand software systems. On the other hand, some believe that refactoring has the risk of functionality regression and increased testing cost. This paper investigates the impact of refactoring edits on regression tests using the version history of Java open source projects: (1) Are there adequate regression tests for refactoring in practice? (2) How many of existing regression tests are relevant to refactoring edits and thus need to be re-run for the new version? (3) What proportion of failure-inducing changes are relevant to refactorings? By using a refactoring reconstruction analysis and a change impact analysis in tandem, we investigate the relationship between the types and locations of refactoring edits identified by RefFinder and the affecting changes and affected tests identified by the FaultTracer change impact analysis. The results on three open source projects, JMeter, XMLSecurity, and ANT, show that only 22% of refactored methods and fields are tested by existing regression tests. While refactorings only constitutes 8% of atomic changes, 38% of affected tests are relevant to refactorings. Furthermore, refactorings are involved in almost half of the failed test cases. These results call for new automated regression test augmentation and selection techniques for validating refactoring edits.
Software Maintenance (ICSM), 2012 28th IEEE International Conference on; 09/2012
Data provided are for informational purposes only. Although carefully collected, accuracy cannot be guaranteed. The impact factor represents a rough estimation of the journal's impact factor and does not reflect the actual current impact factor. Publisher conditions are provided by RoMEO. Differing provisions from the publisher's actual policy or licence agreement may be applicable.