Ran Ettinger Advanced Software Tools Seminar Tel Aviv University June 8, 2009

1. Impressions from WRT @ OOPSLA 2008The 2nd Workshop on Refactoring ToolsAt the Conference onObject Oriented Programming, Systems, Languages, and Applications,Nashville, Tennessee Ran Ettinger Advanced Software Tools Seminar Tel Aviv University June 8, 2009

2. WRT: Implementing Refactorings in IntelliJ IDEA • By Dmitry Jemerov of JetBrains • “IntelliJ IDEA was one of the first Java IDEs to cross the Refactoring Rubicon” • Extract Method Object • Instead of rejecting an Extract Method refactoring, when two or more variables must be returned • Change the type in a variable’s declaration • Looking to more languages (e.g., Ruby) • Ad hoc support for each new language • General mechanism for (user-specified) structural search + rewriting • Somewhat similar to Project Jackpot (NetBeans) • Towards a domain specific language for refactoring tools • Some support for refactoring code with syntax errors

3. WRT: Designing Refactoring Tools for Developers • DevExpress: Dustin Campbell (moved to Microsoft) and Mark Miller • Barriers between programmers and refactoring tools • Discoverability: Provide a context menu with available transformations • Lack of trust or lack of familiarity: Preview hinting – no commitment on the side of the programmer • Productivity: one keyboard shortcut for all refactorings (no mouse); no modal dialogs – instead, all user input is entered on the context menu and inside the code editor • Animated reversal of parameters • Reversal of conditional (then and else) • Replace result temp with return statements • Some 150 micro-refactorings • Basic support for C++ (not so successful)

4. WRT: Analyzing Tool Usage • By Joshua Kerievsky of IndustrialLogic • Author of Refactoring to Patterns • No longer believes in printed books • Online albums including recorded sessions of refactorings • Online labs with refactoring exercises • Let the student program • Track behavior through recording refactoring history (tool in Eclipse) • Check good practices: frequent testing, effective usage of tools • Show code before and after • Test-Driven Development (TDD) labs too • Refactoring rash

5. WRT: Gathering Refactoring Data: a Comparison of Four Methods • By Emerson Murphy-Hill, Andrew P. Black, Danny Dig, and Chris Parnin • Followed by ICSE09 best paper How We Refactor, and How We Know It • Method 1: Mining the Commit Log • Method 2: Analyzing Code Histories • Method 3: Observing Programmers • Method 4: Logging Refactoring Tool Use

6. WRT: Refactoring is not (yet) about transformation • By Torbjörn Ekman, Max Schäfer, and Mathieu Verbaere • Refactoring = Analysis + Transformation • Analysis is hard: Bugs in all tools! • Integration with a compiler, to gain correctness, reusability and extensibility • A refactoring engine is based on JastAddJ • Hopefully… Refactoring can be just about transformation!

7. WRT: Refactoring a Language for Parallel Computational Chemistry • By Beverly A. Sanders, Erik Deumens, Victor Lotrich, and Mark Ponton • Refactor for performance (parallelism) while preserving correctness, not necessarily behavior! • Users are chemical scientists (more than they are programmers) • Merge loops • Exchange (nested) loops • Eliminate redundant matrix transposes • IMP-based tool (in Eclipse) for a language called SIAL

8. WRT: Refactoring Code to Use Concurrent Library Utilities • By Danny Dig, John Marrero, and Michael D. Ernst • Refactoring for thread safety and scalability (multicore) • Java 7 • Replace int with AtomicInteger • Replace HashMap with ConcurrentHashMap • Naive usage of syncronized too expensive (performance overhead) • Tool called Concurrencer • Require data-flow analysis; side effects too • Future: replace an array with a concurrent array (Java 7)

9. WRT: Some more… • Tool Support for Refactoring Functional Programs by Huiqing Li and Simon Thompson • Haskell, Erlang • Practical Refactoring-Based Framework Upgrade by Ilie Savga, Michael Rudolf, Sebastian Götz, and Uwe Aßmann (appeared in the co-located Conference on Generative Programming and Component Engineering – GPCE) • Refactorings comprise 75-97% of application-breaking API changes • Refactoring treated as a formal spec of syntactic changes • Comebacks: Refactoring Inverses on Adapters • A comeback is a refactoring transforming adapters to compensate for a framework refactoring. (They consider the addition of functionality also a refactoring!) • Introduce an adaptation layer between frameworks and plugins • Re-Approaching the Refactoring Rubicon by Aharon Abadi, Ran Ettinger, and Yishai Feldman

10. OOPSLA Essay: Designed as Designer • By Richard P. Gabriel • “Conceptual integrity arises not (simply) from one mind or from a small number of agreeing resonant minds, but from sometimes hidden co-authors and the thing designed itself.” • First to the market myth is false • Counterexamples: Gillete, Pampers • Fred Brooks is wrong (in his OOPSLA 2007 Keynote) • Good design is rarely due to one (or at most two) designers • Many other (people) contribute • Even the thing being designed • In poetry, painting, architecture (Brunelleschi’s dome of Florence), language design (Lisp, Scheme, Actors and Closures), academic research, and software too • “There’s something about our culture that seems to love heroes, that looks for the genius who’s solved it all, that seems to need to believe the first to market—the best inventor—reaps justly deserved rewards.”

11. OOPSLA: Practitioner Reports • Performance Pitfalls in Large-Scale Java Applications Translated from COBOL • Toshio Suganuma, Toshiaki Yasue, Tamiya Onodera, and Toshio Nakatani (IBM Tokyo Research Laboratory) • Retaining Comments when Refactoring Code • Prof. Peter Sommerlad, Guido Zgraggen, Thomas Corbat, and Lukas Felber (IFS Institute for Software at HSR Rapperswil) • AST is too abstract for refactoring tools! • Removing comments is a valid Refactoring • “Σ value(comment) < 0” (Alan Kelly)

12. OOPSLA Demos • Refactoring Support for the Groovy-Eclipse Plug-in • Martin Kempf, Reto Kleeb, Michael Klenk, Peter Sommerlad (IFS Institute for Software at HSR Rapperswil) • “This article presents our refactoring plug-in for the Groovy-Eclipse Plug-in. Refactoring is a very important technique for every software engineer to ensure the healthiness of his code and a cornerstone of agile software development. In our project we introduce refactoring support for Groovy-Eclipse, with six automated refactorings as well as a source code formatter. Since Java and Groovy are that closely related we also analyzed and documented the options to introduce crosslanguage refactorings between Java and Groovy.” • Axiom-Based Testing for C++ • Anya Helene Bagge, Valentin David, and Magne Haveraaen • “Axioms, known from program specification, allow program functionality to be described as rules or equations. The draft C++0x standard introduces axioms as part of the new concept feature. We will demonstrate a tool that uses these features for automated unit testing.”

13. OOPSLA: Some highlights from the technical program • Sound and Extensible Renaming for Java • Max Schäfer, Torbjörn Ekman, and Oege de Moor (Oxford) • The VISITOR Pattern as a Reusable, Generic, Type-Safe Component • Bruno Oliveira, Meng Wang, and Jeremy Gibbons (Oxford) • Whiteoak: Introducing Structural Typing into Java • Yossi Gil and Itay Maman (Technion) • QVM: An Efficient Runtime for Detecting Defects in Deployed Systems • Matthew Arnold, Martin Vechev, and Eran Yahav (IBM Research)