Program Metamorphosis

Reichenbach, Christoph; Coughlin, Devin; Diwan, Amer

doi:10.1007/978-3-642-03013-0_18

Cited by 17 publications

(13 citation statements)

References 8 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…For instance, previous work [25,32] has discussed swapping two names, e.g., transforming field declarations String s1; String s2; to String s2; String s1;, changing uses of s1 and s2 appropriately. One cannot apply the RENAME refactoring to first change s1 to s2 or viceversa, since a name conflict arises.…”

Section: Overviewmentioning

confidence: 99%

“…The first five examples are transformations presented in Fowler [6] that are not implemented in Eclipse, but can be accomplished via a sequence of the refactorings we have implemented. We also include two examples of name swapping refactorings that have appeared in the literature [25,32], each of which requires a non-obvious introduction of a temporary name in the refactoring sequence. Finally, the INTRO-DUCE PARAMETER example, found online, can be achieved via a complex sequence of six of our implemented refactorings.…”

Section: Refactoring Sequencesmentioning

confidence: 99%

“…This means that it will sometimes fail to infer a sequence of refactorings if some intermediate step cannot be performed using the available refactorings. This problem could be alleviated by instead basing RESYNTH on more fine-grained transformations as proposed in the literature [25,27].…”

Section: Related Workmentioning

confidence: 99%

See 2 more Smart Citations

Refactoring with synthesis

Raychev

Schäfer

Sridharan

et al. 2013

Proceedings of the 2013 ACM SIGPLAN International Conference on Object Oriented Programming Systems Languages &Amp; Application

View full text Add to dashboard Cite

Refactoring has become an integral part of modern software development, with wide support in popular integrated development environments (IDEs). Modern IDEs provide a fixed set of supported refactorings, listed in a refactoring menu. But with IDEs supporting more and more refactorings, it is becoming increasingly difficult for programmers to discover and memorize all their names and meanings. Also, since the set of refactorings is hard-coded, if a programmer wants to achieve a slightly different code transformation, she has to either apply a (possibly non-obvious) sequence of several built-in refactorings, or just perform the transformation by hand.We propose a novel synthesis system which addresses these limitations. Our system employs a recently proposed refactoring interface, in which a refactoring is achieved via three simple steps: the programmer first indicates the start of a code refactoring phase; then she performs some of the desired code changes manually; and finally, she asks the tool to complete the refactoring.Given the initial and modified programs, our synthesis system completes the refactoring by first extracting the difference between the starting program and the modified version, and then synthesizing a sequence of refactorings that achieves (at least) the desired changes. To enable scalable synthesis, we introduce local refactorings, which allow for first discovering a refactoring sequence on small program fragments and then extrapolating it to a full refactoring sequence.We implemented our approach as an Eclipse plug-in, with an architecture that is easily extendable with new refactorings. The experimental results are encouraging: with only minimal user input, the synthesizer was able to quickly discover complex refactoring sequences for several challenging realistic examples.

show abstract

Section: Overviewmentioning

confidence: 99%

Section: Refactoring Sequencesmentioning

confidence: 99%

See 1 more Smart Citation

Refactoring with synthesis

Raychev

Schäfer

Sridharan

et al. 2013

Proceedings of the 2013 ACM SIGPLAN International Conference on Object Oriented Programming Systems Languages &Amp; Application

View full text Add to dashboard Cite

show abstract

“…For example, program metamorphosis [Reichenbach et al 2009], a generalization of traditional refactoring, materializes such concerns as persistent warnings that users can review during the refactoring process. This is analogous to a static bug report issued by FindBugs in that developers may now raise objections, such as "this method is private and not supposed to ever be called via reflection.…”

Section: Applicability To Refactoringmentioning

confidence: 99%

Residual Investigation

Reichenbach

Csallner

et al. 2014

ACM Trans. Softw. Eng. Methodol.

Self Cite

View full text Add to dashboard Cite

We introduce the concept of residual investigation for program analysis. A residual investigation is a dynamic check installed as a result of running a static analysis that reports a possible program error. The purpose is to observe conditions that indicate whether the statically predicted program fault is likely to be realizable and relevant. The key feature of a residual investigation is that it has to be much more precise (i.e., with fewer false warnings) than the static analysis alone, yet significantly more general (i.e., reporting more errors) than the dynamic tests in the program's test suite that are pertinent to the statically reported error. That is, good residual investigations encode dynamic conditions that, when considered in conjunction with the static error report, increase confidence in the existence or severity of an error without needing to directly observe a fault resulting from the error.We enhance the static analyzer FindBugs with several residual investigations appropriately tuned to the static error patterns in FindBugs, and apply it to nine large open-source systems and their native test suites. The result is an analysis with a low occurrence of false warnings (false positives) while reporting several actual errors that would not have been detected by mere execution of a program's test suite.

show abstract

“…Later work considered various features of sequential programs such as class hierarchies [12,28,29], generics [5,6,14,31], design patterns [13], and access modifiers [27]. Other research has focused on refactoring support to adapt programs to evolving libraries [3], combining refactorings with other programs transformations [22], empirical studies [18,19], and domain-specific languages for specifying refactorings [30].…”

Section: Related Workmentioning

confidence: 99%

Refactoring Java programs for flexible locking

Schäfer

Sridharan

Dolby

et al. 2011

Proceedings of the 33rd International Conference on Software Engineering

View full text Add to dashboard Cite

Recent versions of the Java standard library offer flexible locking constructs that go beyond the language's built-in monitor locks in terms of features, and that can be fine-tuned to suit specific application scenarios. Under certain conditions, the use of these constructs can improve performance significantly, by reducing lock contention. However, the code transformations needed to convert between locking constructs are non-trivial, and great care must be taken to update lock usage throughout the program consistently. We present Relocker, an automated tool that assists programmers with refactoring synchronized blocks into ReentrantLocks and ReadWriteLocks, to make exploring the performance tradeoffs among these constructs easier. In experiments on a collection of real-world Java applications, Relocker was able to refactor over 80% of built-in monitors into ReentrantLocks. Additionally, in most cases the tool could automatically infer the same ReadWriteLock usage that programmers had previously introduced manually.

show abstract

Program Metamorphosis

Cited by 17 publications

References 8 publications

Refactoring with synthesis

Refactoring with synthesis

Residual Investigation

Refactoring Java programs for flexible locking

Contact Info

Product

Resources

About