-\documentclass[USenglish]{ifimaster}
+\documentclass[USenglish,11pt]{ifimaster}
\usepackage{import}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc,url}
\usepackage{lmodern} % using Latin Modern to be able to use bold typewriter font
+%\usepackage{mathpazo}
\urlstyle{sf}
\usepackage{listings}
+\usepackage{booktabs}
\usepackage{tabularx}
\usepackage{tikz}
\usepackage{tikz-qtree}
\usetikzlibrary{shapes,snakes,trees,arrows,shadows,positioning,calc}
-\usepackage{babel,textcomp,csquotes,ifimasterforside,varioref}
+\usepackage{babel,textcomp,csquotes,ifimasterforside}
+
+\usepackage{varioref}
\usepackage[hidelinks]{hyperref}
\usepackage{cleveref}
-\usepackage[style=alphabetic,backend=bibtex]{biblatex}
+\usepackage[xindy]{glossaries}
+
+\usepackage[style=alphabetic,backend=biber,doi=false,isbn=false]{biblatex}
\usepackage{amsthm}
+\usepackage{mathtools}
\usepackage{graphicx}
% use 'disable' before printing:
\usepackage[]{todonotes}
\usepackage{minted}
\usepackage{multicol}
\usemintedstyle{bw}
+
+\def\mintedframesep{11pt}
+
\usepackage{perpage} %the perpage package
\MakePerPage{footnote} %the perpage package command
\theoremstyle{definition}
\newtheorem*{wordDef}{Definition}
+\newtheorem*{theorem}{Theorem}
\graphicspath{ {./figures/} }
\newcommand{\citing}[1]{~\cite{#1}}
-\newcommand{\myref}[1]{\cref{#1} on \cpageref{#1}}
+%\newcommand{\myref}[1]{\cref{#1} on \cpageref{#1}}
+\newcommand{\myref}[1]{\vref{#1}}
+\newcommand{\Myref}[1]{\Vref{#1}}
+
+%\newcommand{\glossref}[1]{\textsuperscript{(\glsrefentry{#1})}}
+%\newcommand{\gloss}[1]{\gls{#1}\glossref{#1}}
+%\newcommand{\glosspl}[1]{\glspl{#1}\glossref{#1}}
+\newcommand{\gloss}[1]{\gls{#1}}
+\newcommand{\glosspl}[1]{\glspl{#1}}
\newcommand{\definition}[1]{\begin{wordDef}#1\end{wordDef}}
\newcommand{\see}[1]{(see \myref{#1})}
-\newcommand{\See}[1]{(See \myref{#1}.)}
\newcommand{\explanation}[3]{\noindent\textbf{\textit{#1}}\\*\emph{When:}
#2\\*\emph{How:} #3\\*[-7px]}
\newcommand{\methodwithref}[2]{\method{#2}\footnote{\type{#1}\method{\##2()}}}
\newcommand{\var}[1]{\type{#1}}
-\newcommand{\refactoring}[1]{\emph{#1}}
-\newcommand{\ExtractMethod}{\refactoring{Extract Method}\xspace}
-\newcommand{\MoveMethod}{\refactoring{Move Method}\xspace}
-\newcommand{\ExtractAndMoveMethod}{\refactoring{Extract and Move Method}\xspace}
+\newcommand{\name}[1]{#1}
+\newcommand{\tit}[1]{\emph{#1}}
+\newcommand{\refa}[1]{\emph{#1}}
+\newcommand{\pattern}[1]{\emph{#1}}
+\newcommand{\metr}[1]{\emph{#1}}
+\newcommand{\ExtractMethod}{\refa{Extract Method}\xspace}
+\newcommand{\MoveMethod}{\refa{Move Method}\xspace}
+\newcommand{\ExtractAndMoveMethod}{\refa{Extract and Move Method}\xspace}
+
+\newcommand{\m}[1]{$#1$}
-\newcommand\todoin[2][]{\todo[inline, caption={2do}, #1]{
+\newcommand\todoin[2][]{\todo[inline, caption={#2}, #1]{
\begin{minipage}{\textwidth-4pt}#2\end{minipage}}}
-\title{Refactoring}
-\subtitle{An essay}
+\title{Automated Composition of Refactorings}
+\subtitle{Implementing and evaluating a search-based Extract and Move Method
+refactoring}
\author{Erlend Kristiansen}
+\makeglossaries
+\newglossaryentry{profiling}
+{
+ name=profiling,
+ description={is to run a computer program through a profiler/with a profiler
+ attached}
+}
+\newglossaryentry{profiler}
+{
+ name=profiler,
+ description={A profiler is a program for analyzing performance within an
+ application. It is used to analyze memory consumption, processing time and
+frequency of procedure calls and such}
+}
+\newglossaryentry{xUnit}
+{
+ name={xUnit framework},
+ description={An xUnit framework is a framework for writing unit tests for a
+ computer program. It follows the patterns known from the JUnit framework for
+ Java\citing{fowlerXunit}
+ },
+ plural={xUnit frameworks}
+}
+\newglossaryentry{softwareObfuscation}
+{
+ name={software obfuscation},
+ description={makes source code harder to read and analyze, while preserving
+ its semantics}
+}
+\newglossaryentry{extractClass}
+{
+ name=\refa{Extract Class},
+ description={The \refa{Extract Class} refactoring works by creating a class,
+for then to move members from another class to that class and access them from
+the old class via a reference to the new class}
+}
+\newglossaryentry{designPattern}
+{
+ name={design pattern},
+ description={A design pattern is a named abstraction, that is meant to solve a
+ general design problem. It describes the key aspects of a common problem and
+identifies its participators and how they collaborate},
+ plural={design patterns}
+}
+\newglossaryentry{enclosingClass}
+{
+ name={enclosing class},
+ description={An enclosing class is the class that surrounds any specific piece
+ of code that is written in the inner scope of this class},
+}
+\newglossaryentry{mementoPattern}
+{
+ name={memento pattern},
+ description={The memento pattern is a software design pattern that is used to
+ capture an object's internal state so that it can be restored to this state
+ later\citing{designPatterns}},
+}
+%\newglossaryentry{extractMethod}
+%{
+% name=\refa{Extract Method},
+% description={The \refa{Extract Method} refactoring is used to extract a
+%fragment of code from its context and into a new method. A call to the new
+%method is inlined where the fragment was before. It is used to break code into
+%logical units, with names that explain their purpose}
+%}
+%\newglossaryentry{moveMethod}
+%{
+% name=\refa{Move Method},
+% description={The \refa{Move Method} refactoring is used to move a method from
+% one class to another. This is useful if the method is using more features of
+% another class than of the class which it is currently defined. Then all calls
+% to this method must be updated, or the method must be copied, with the old
+%method delegating to the new method}
+%}
+
\bibliography{bibliography/master-thesis-erlenkr-bibliography}
+\DefineBibliographyStrings{english}{%
+ bibliography = {References},
+}
+\newbibmacro{string+doi}[1]{%
+ \iffieldundef{doi}{#1}{\href{http://dx.doi.org/\thefield{doi}}{#1}}}
+\DeclareFieldFormat{title}{\usebibmacro{string+doi}{\mkbibemph{#1}}}
+\DeclareFieldFormat[article]{title}{\usebibmacro{string+doi}{\mkbibquote{#1}}}
- % UML comment in TikZ:
- % ref: https://tex.stackexchange.com/questions/103688/folded-paper-shape-tikz
+% UML comment in TikZ:
+% ref: https://tex.stackexchange.com/questions/103688/folded-paper-shape-tikz
\makeatletter
\pgfdeclareshape{umlcomment}{
\inheritsavedanchors[from=rectangle] % this is nearly a rectangle
font=\ttfamily,
]
+%\interfootnotelinepenalty=10000
+
+% Space between table rows
+\renewcommand{\arraystretch}{1.3}
+% Multicolumns
+\newcommand{\spancols}[2]{\multicolumn{#1}{@{}l@{}}{#2}}
+% Column types
+\newcolumntype{L}[1]{>{\hsize=#1\hsize\raggedright\arraybackslash}X}%
+\newcolumntype{R}[1]{>{\hsize=#1\hsize\raggedleft\arraybackslash}X}%
+
+
\begin{document}
+%\pagenumbering{arabic}
+\mainmatter
\ififorside
-\frontmatter{}
+%\frontmatter{}
+%\setcounter{page}{3}
\chapter*{Abstract}
\todoin{\textbf{Remove all todos (including list) before delivery/printing!!!
\tableofcontents{}
\listoffigures{}
\listoftables{}
+\listoflistings{}
-\chapter*{Preface}
+%\mainmatter
+%\setcounter{page}{13}
-The discussions in this report must be seen in the context of object oriented
-programming languages, and Java in particular, since that is the language in
-which most of the examples will be given. All though the techniques discussed
-may be applicable to languages from other paradigms, they will not be the
-subject of this report.
+\chapter{Introduction}
-\mainmatter
+\section{Motivation and structure}
+
+For large software projects, complex program source code is an issue. It impacts
+the cost of maintenance in a negative way. It often stalls the implementation of
+new functionality and other program changes. The code may be difficult to
+understand, the changes may introduce new bugs that are hard to find and its
+complexity can simply keep people from doing code changes in fear of breaking
+some dependent piece of code. All these problems are related, and often lead to
+a vicious circle that slowly degrades the overall quality of a project.
+
+More specifically, and in an object-oriented context, a class may depend on a
+number of other classes. Sometimes these intimate relationships are appropriate,
+and sometimes they are not. Inappropriate \emph{coupling} between classes can
+make it difficult to know whether or not a change that is aimed at fixing a
+specific problem also alters the behavior of another part of a program.
-\chapter{What is Refactoring?}
+One of the tools that are used to fight complexity and coupling in program
+source code is \emph{refactoring}. The intention for this master's thesis is
+therefore to create an automated composite refactoring that reduces coupling
+between classes. The refactoring shall be able to operate automatically in all
+phases of a refactoring, from performing analysis to executing changes. It is
+also a requirement that it should be able to process large quantities of source
+code in a reasonable amount of time.
+
+
+\todoin{Structure. Write later\ldots}
+
+
+\section{What is refactoring?}
This question is best answered by first defining the concept of a
\emph{refactoring}, what it is to \emph{refactor}, and then discuss what aspects
of programming make people want to refactor their code.
-\section{Defining refactoring}
+\subsection{Defining refactoring}
Martin Fowler, in his classic book on refactoring\citing{refactoring}, defines a
refactoring like this:
on the performance of a program could make the program behave differently after
a refactoring.
-In the extreme case one could argue that such a thing as \emph{software
-obfuscation} is refactoring. Software obfuscation is to make source code harder
-to read and analyze, while preserving its semantics. It could be done composing
-many, more or less randomly chosen, refactorings. Then the question arise
-whether it can be called a \emph{composite refactoring}
-\see{compositeRefactorings} or not? The answer is not obvious. First, there is
-no way to describe \emph{the} mechanics of software obfuscation, beacause there
-are infinitely many ways to do that. Second, \emph{obfuscation} can be thought
-of as \emph{one operation}: Either the code is obfuscated, or it is not. Third,
-it makes no sense to call software obfuscation \emph{a} refactoring, since it
-holds different meaning to different people. The last point is important, since
-one of the motivations behind defining different refactorings is to build up a
-vocabulary for software professionals to reason and discuss about programs,
-similar to the motivation behind design patterns\citing{designPatterns}. So for
-describing \emph{software obfuscation}, it might be more appropriate to define
-what you do when performing it rather than precisely defining its mechanics in
-terms of other refactorings.
-
-\section{The etymology of 'refactoring'}
+In the extreme case one could argue that \gloss{softwareObfuscation} is
+refactoring. It is often used to protect proprietary software. It restrains
+uninvited viewers, so they have a hard time analyzing code that they are not
+supposed to know how works. This could be a problem when using a language that
+is possible to decompile, such as Java.
+
+Obfuscation could be done composing many, more or less randomly chosen,
+refactorings. Then the question arises whether it can be called a
+\emph{composite refactoring} or not \see{compositeRefactorings}? The answer is
+not obvious. First, there is no way to describe the mechanics of software
+obfuscation, because there are infinitely many ways to do that. Second,
+obfuscation can be thought of as \emph{one operation}: Either the code is
+obfuscated, or it is not. Third, it makes no sense to call software obfuscation
+\emph{a refactoring}, since it holds different meaning to different people.
+
+This last point is important, since one of the motivations behind defining
+different refactorings, is to establish a \emph{vocabulary} for software
+professionals to use when reasoning about and discussing programs, similar to
+the motivation behind \glosspl{designPattern}\citing{designPatterns}.
+\begin{comment}
+So for describing \emph{software obfuscation}, it might be more appropriate to
+define what you do when performing it rather than precisely defining its
+mechanics in terms of other refactorings.
+\end{comment}
+
+\subsection{The etymology of 'refactoring'}
It is a little difficult to pinpoint the exact origin of the word
``refactoring'', as it seems to have evolved as part of a colloquial
terminology, more than a scientific term. There is no authoritative source for a
According to Martin Fowler\citing{etymology-refactoring}, there may also be more
than one origin of the word. The most well-known source, when it comes to the
-origin of \emph{refactoring}, is the Smalltalk\footnote{\emph{Smalltalk},
-object-oriented, dynamically typed, reflective programming language. See
-\url{http://www.smalltalk.org}} community and their infamous \emph{Refactoring
+origin of \emph{refactoring}, is the
+Smalltalk\footnote{\label{footNote}Programming language} community and their
+infamous \name{Refactoring
Browser}\footnote{\url{http://st-www.cs.illinois.edu/users/brant/Refactory/RefactoringBrowser.html}}
-described in the article \emph{A Refactoring Tool for
+described in the article \tit{A Refactoring Tool for
Smalltalk}\citing{refactoringBrowser1997}, published in 1997.
Allegedly\citing{etymology-refactoring}, the metaphor of factoring programs was
-also present in the Forth\footnote{\emph{Forth} -- stack-based, extensible
-programming language, without type-checking. See \url{http://www.forth.org}}
-community, and the word ``refactoring'' is mentioned in a book by Leo Brodie,
-called \emph{Thinking Forth}\citing{brodie1984}, first published in
-1984\footnote{\emph{Thinking Forth} was first published in 1984 by the
-\emph{Forth Interest Group}. Then it was reprinted in 1994 with minor
-typographical corrections, before it was transcribed into an electronic edition
-typeset in \LaTeX\ and published under a Creative Commons licence in 2004. The
-edition cited here is the 2004 edition, but the content should essentially be as
-in 1984.}. The exact word is only printed one place~\cite[p.~232]{brodie1984},
-but the term \emph{factoring} is prominent in the book, that also contains a
-whole chapter dedicated to (re)factoring, and how to keep the (Forth) code clean
-and maintainable.
+also present in the Forth\textsuperscript{\ref{footNote}} community, and the
+word ``refactoring'' is mentioned in a book by Leo Brodie, called \tit{Thinking
+Forth}\citing{brodie2004}, first published in 1984\footnote{\tit{Thinking Forth}
+was first published in 1984 by the \name{Forth Interest Group}. Then it was
+reprinted in 1994 with minor typographical corrections, before it was
+transcribed into an electronic edition typeset in \LaTeX\ and published under a
+Creative Commons licence in
+2004. The edition cited here is the 2004 edition, but the content should
+essentially be as in 1984.}. The exact word is only printed one
+place~\cite[p.~232]{brodie2004}, but the term \emph{factoring} is prominent in
+the book, that also contains a whole chapter dedicated to (re)factoring, and how
+to keep the (Forth) code clean and maintainable.
\begin{quote}
\ldots good factoring technique is perhaps the most important skill for a
- Forth programmer.~\cite[p.~172]{brodie1984}
+ Forth programmer.~\cite[p.~172]{brodie2004}
\end{quote}
\noindent Brodie also express what \emph{factoring} means to him:
Factoring means organizing code into useful fragments. To make a fragment
useful, you often must separate reusable parts from non-reusable parts. The
reusable parts become new definitions. The non-reusable parts become arguments
- or parameters to the definitions.~\cite[p.~172]{brodie1984}
+ or parameters to the definitions.~\cite[p.~172]{brodie2004}
\end{quote}
Fowler claims that the usage of the word \emph{refactoring} did not pass between
-the \emph{Forth} and \emph{Smalltalk} communities, but that it emerged
+the \name{Forth} and \name{Smalltalk} communities, but that it emerged
independently in each of the communities.
-\section{Motivation -- Why people refactor}
+\subsection{Reasons for refactoring}
There are many reasons why people want to refactor their programs. They can for
instance do it to remove duplication, break up long methods or to introduce
-design patterns\citing{designPatterns} into their software systems. The shared
-trait for all these are that peoples intentions are to make their programs
-\emph{better}, in some sense. But what aspects of their programs are becoming
-improved?
-
-As already mentioned, people often refactor to get rid of duplication. Moving
-identical or similar code into methods, and maybe pushing methods up or down in
-their class hierarchies. Making template methods for overlapping
-algorithms/functionality and so on. It is all about gathering what belongs
-together and putting it all in one place. The resulting code is then easier to
-maintain. When removing the implicit coupling\footnote{When duplicating code,
-the code might not be coupled in other ways than that it is supposed to
-represent the same functionality. So if this functionality is going to change,
-it might need to change in more than one place, thus creating an implicit
-coupling between the multiple pieces of code.} between code snippets, the
+design patterns into their software systems. The shared trait for all these are
+that peoples' intentions are to make their programs \emph{better}, in some
+sense. But what aspects of their programs are becoming improved?
+
+As just mentioned, people often refactor to get rid of duplication. They are
+moving identical or similar code into methods, and are pushing methods up or
+down in their class hierarchies. They are making template methods for
+overlapping algorithms/functionality, and so on. It is all about gathering what
+belongs together and putting it all in one place. The resulting code is then
+easier to maintain. When removing the implicit coupling\footnote{When
+ duplicating code, the duplicate pieces of code might not be coupled, apart
+from representing the same functionality. So if this functionality is going to
+change, it might need to change in more than one place, thus creating an
+implicit coupling between multiple pieces of code.} between code snippets, the
location of a bug is limited to only one place, and new functionality need only
to be added to this one place, instead of a number of places people might not
even remember.
A problem you often encounter when programming, is that a program contains a lot
of long and hard-to-grasp methods. It can then help to break the methods into
-smaller ones, using the \ExtractMethod refactoring\citing{refactoring}. Then you
-may discover something about a program that you were not aware of before;
+smaller ones, using the \ExtractMethod refactoring\citing{refactoring}. Then
+you may discover something about a program that you were not aware of before;
revealing bugs you did not know about or could not find due to the complex
-structure of your program. \todo{Proof?} Making the methods smaller and giving
-good names to the new ones clarifies the algorithms and enhances the
-\emph{understandability} of the program \see{magic_number_seven}. This makes
-refactoring an excellent method for exploring unknown program code, or code that
-you had forgotten that you wrote.
-
-Most primitive refactorings are simple. Their true power is first revealed when
-they are combined into larger --- higher level --- refactorings, called
+structure of your program. Making the methods smaller and giving good names to
+the new ones clarifies the algorithms and enhances the \emph{understandability}
+of the program \see{magic_number_seven}. This makes refactoring an excellent
+method for exploring unknown program code, or code that you had forgotten that
+you wrote.
+
+Most primitive refactorings are simple, and usually involves moving code
+around\citing{kerievsky2005}. The motivation behind them may first be revealed
+when they are combined into larger --- higher level --- refactorings, called
\emph{composite refactorings} \see{compositeRefactorings}. Often the goal of
-such a series of refactorings is a design pattern. Thus the \emph{design} can be
-evolved throughout the lifetime of a program, as opposed to designing up-front.
-It is all about being structured and taking small steps to improve a program's
-design.
+such a series of refactorings is a design pattern. Thus the design can
+\emph{evolve} throughout the lifetime of a program, as opposed to designing
+up-front. It is all about being structured and taking small steps to improve a
+program's design.
Many software design pattern are aimed at lowering the coupling between
different classes and different layers of logic. One of the most famous is
-perhaps the \emph{Model-View-Controller}\citing{designPatterns} pattern. It is
-aimed at lowering the coupling between the user interface and the business logic
-and data representation of a program. This also has the added benefit that the
-business logic could much easier be the target of automated tests, increasing
-the productivity in the software development process. Refactoring is an
-important tool on the way to something greater.
+perhaps the \pattern{Model-View-Controller}\citing{designPatterns} pattern. It
+is aimed at lowering the coupling between the user interface, the business logic
+and the data representation of a program. This also has the added benefit that
+the business logic could much easier be the target of automated tests, thus
+increasing the productivity in the software development process.
Another effect of refactoring is that with the increased separation of concerns
coming out of many refactorings, the \emph{performance} can be improved. When
profiling programs, the problematic parts are narrowed down to smaller parts of
the code, which are easier to tune, and optimization can be performed only where
-needed and in a more effective way.
+needed and in a more effective way\citing{refactoring}.
Last, but not least, and this should probably be the best reason to refactor, is
to refactor to \emph{facilitate a program change}. If one has managed to keep
and money should also be able to open the eyes of the many nearsighted managers
that seldom see beyond the next milestone.
-\section{The magical number seven}\label{magic_number_seven}
-The article \emph{The magical number seven, plus or minus two: some limits on
-our capacity for processing information}\citing{miller1956} by George A.
-Miller, was published in the journal \emph{Psychological Review} in 1956. It
-presents evidence that support that the capacity of the number of objects a
-human being can hold in its working memory is roughly seven, plus or minus two
-objects. This number varies a bit depending on the nature and complexity of the
-objects, but is according to Miller ``\ldots never changing so much as to be
+\subsection{The magical number seven}\label{magic_number_seven}
+The article \tit{The magical number seven, plus or minus two: some limits on our
+capacity for processing information}\citing{miller1956} by George A. Miller,
+was published in the journal \name{Psychological Review} in 1956. It presents
+evidence that support that the capacity of the number of objects a human being
+can hold in its working memory is roughly seven, plus or minus two objects. This
+number varies a bit depending on the nature and complexity of the objects, but
+is according to Miller ``\ldots never changing so much as to be
unrecognizable.''
Miller's article culminates in the section called \emph{Recoding}, a term he
borrows from communication theory. The central result in this section is that by
recoding information, the capacity of the amount of information that a human can
process at a time is increased. By \emph{recoding}, Miller means to group
-objects together in chunks and give each chunk a new name that it can be
-remembered by. By organizing objects into patterns of ever growing depth, one
-can memorize and process a much larger amount of data than if it were to be
-represented as its basic pieces. This grouping and renaming is analogous to how
-many refactorings work, by grouping pieces of code and give them a new name.
-Examples are the fundamental \ExtractMethod and \refactoring{Extract Class}
-refactorings\citing{refactoring}.
+objects together in chunks, and give each chunk a new name that it can be
+remembered by.
\begin{quote}
\ldots recoding is an extremely powerful weapon for increasing the amount of
information that we can deal with.~\cite[p.~95]{miller1956}
\end{quote}
+By organizing objects into patterns of ever growing depth, one can memorize and
+process a much larger amount of data than if it were to be represented as its
+basic pieces. This grouping and renaming is analogous to how many refactorings
+work, by grouping pieces of code and give them a new name. Examples are the
+fundamental \ExtractMethod and \refa{Extract Class}
+refactorings\citing{refactoring}.
+
An example from the article addresses the problem of memorizing a sequence of
-binary digits. Let us say we have the following sequence\footnote{The example
- presented here is slightly modified (and shortened) from what is presented in
- the original article\citing{miller1956}, but it is essentially the same.} of
+binary digits. The example presented here is a slightly modified version of the
+one presented in the original article\citing{miller1956}, but it preserves the
+essence of it. Let us say we have the following sequence of
16 binary digits: ``1010001001110011''. Most of us will have a hard time
memorizing this sequence by only reading it once or twice. Imagine if we instead
translate it to this sequence: ``A273''. If you have a background from computer
-science, it will be obvious that the latest sequence is the first sequence
-recoded to be represented by digits with base 16. Most people should be able to
+science, it will be obvious that the latter sequence is the first sequence
+recoded to be represented by digits in base 16. Most people should be able to
memorize this last sequence by only looking at it once.
Another result from the Miller article is that when the amount of information a
Then they can learn distinct words, and later read sequences of words that form
whole sentences. Eventually, most of them will be able to read whole books and
briefly retell the important parts of its content. This suggest that the use of
-design patterns\citing{designPatterns} is a good idea when reasoning about
-computer programs. With extensive use of design patterns when creating complex
-program structures, one does not always have to read whole classes of code to
-comprehend how they function, it may be sufficient to only see the name of a
-class to almost fully understand its responsibilities.
+design patterns is a good idea when reasoning about computer programs. With
+extensive use of design patterns when creating complex program structures, one
+does not always have to read whole classes of code to comprehend how they
+function, it may be sufficient to only see the name of a class to almost fully
+understand its responsibilities.
\begin{quote}
Our language is tremendously useful for repackaging material into a few chunks
Without further evidence, these results at least indicate that refactoring
source code into smaller units with higher cohesion and, when needed,
introducing appropriate design patterns, should aid in the cause of creating
-computer programs that are easier to maintain and has code that is easier (and
+computer programs that are easier to maintain and have code that is easier (and
better) understood.
-\section{Notable contributions to the refactoring literature}
-\todoin{Update with more contributions}
+\subsection{Notable contributions to the refactoring literature}
\begin{description}
\item[1992] William F. Opdyke submits his doctoral dissertation called
- \emph{Refactoring Object-Oriented Frameworks}\citing{opdyke1992}. This
- work defines a set of refactorings, that are behavior preserving given that
- their preconditions are met. The dissertation is focused on the automation
- of refactorings.
- \item[1999] Martin Fowler et al.: \emph{Refactoring: Improving the Design of
+ \tit{Refactoring Object-Oriented Frameworks}\citing{opdyke1992}. This work
+ defines a set of refactorings, that are behavior preserving given that their
+ preconditions are met. The dissertation is focused on the automation of
+ refactorings.
+ \item[1999] Martin Fowler et al.: \tit{Refactoring: Improving the Design of
Existing Code}\citing{refactoring}. This is maybe the most influential text
on refactoring. It bares similarities with Opdykes thesis\citing{opdyke1992}
in the way that it provides a catalog of refactorings. But Fowler's book is
more about the craft of refactoring, as he focuses on establishing a
vocabulary for refactoring, together with the mechanics of different
refactorings and when to perform them. His methodology is also founded on
- the principles of test-driven development.
- \item[2005] Joshua Kerievsky: \emph{Refactoring to
+ the principles of test-driven development.
+ \item[2005] Joshua Kerievsky: \tit{Refactoring to
Patterns}\citing{kerievsky2005}. This book is heavily influenced by Fowler's
- \emph{Refactoring}\citing{refactoring} and the ``Gang of Four'' \emph{Design
+ \tit{Refactoring}\citing{refactoring} and the ``Gang of Four'' \tit{Design
Patterns}\citing{designPatterns}. It is building on the refactoring
catalogue from Fowler's book, but is trying to bridge the gap between
\emph{refactoring} and \emph{design patterns} by providing a series of
higher-level composite refactorings, that makes code evolve toward or away
- from certain design patterns. The book is trying to build up the readers
+ from certain design patterns. The book is trying to build up the reader's
intuition around \emph{why} one would want to use a particular design
pattern, and not just \emph{how}. The book is encouraging evolutionary
- design. \See{relationToDesignPatterns}
+ design \see{relationToDesignPatterns}.
\end{description}
-\section{Tool support (for Java)}\label{toolSupport}
-This section will briefly compare the refatoring support of the three IDEs
-\emph{Eclipse}\footnote{\url{http://www.eclipse.org/}}, \emph{IntelliJ
-IDEA}\footnote{The IDE under comparison is the \emph{Community Edition},
+\subsection{Tool support (for Java)}\label{toolSupport}
+This section will briefly compare the refactoring support of the three IDEs
+\name{Eclipse}\footnote{\url{http://www.eclipse.org/}}, \name{IntelliJ
+IDEA}\footnote{The IDE under comparison is the \name{Community Edition},
\url{http://www.jetbrains.com/idea/}} and
-\emph{NetBeans}\footnote{\url{https://netbeans.org/}}. These are the most
+\name{NetBeans}\footnote{\url{https://netbeans.org/}}. These are the most
popular Java IDEs\citing{javaReport2011}.
All three IDEs provide support for the most useful refactorings, like the
surprise.
The IDEs seem to have excellent support for the \ExtractMethod refactoring, so
-at least they have all passed the first refactoring
-rubicon\citing{fowlerRubicon2001,secondRubicon2012}.
+at least they have all passed the first ``refactoring
+rubicon''\citing{fowlerRubicon2001,secondRubicon2012}.
-Regarding the \MoveMethod refactoring, the \emph{Eclipse} and \emph{IntelliJ}
+Regarding the \MoveMethod refactoring, the \name{Eclipse} and \name{IntelliJ}
IDEs do the job in very similar manners. In most situations they both do a
satisfying job by producing the expected outcome. But they do nothing to check
that the result does not break the semantics of the program \see{correctness}.
-The \emph{NetBeans} IDE implements this refactoring in a somewhat
-unsophisticated way. For starters, its default destination for the move is
-itself, although it refuses to perform the refactoring if chosen. But the worst
-part is, that if moving the method \method{f} of the class \type{C} to the class
-\type{X}, it will break the code. The result is shown in
-\myref{lst:moveMethod_NetBeans}.
+The \name{NetBeans} IDE implements this refactoring in a somewhat
+unsophisticated way. For starters, the refactoring's default destination for the
+move, is the same class as the method already resides in, although it refuses to
+perform the refactoring if chosen. But the worst part is, that if moving the
+method \method{f} of the class \type{C} to the class \type{X}, it will break the
+code. The result is shown in \myref{lst:moveMethod_NetBeans}.
\begin{listing}
\begin{multicols}{2}
\label{lst:moveMethod_NetBeans}
\end{listing}
-NetBeans will try to make code that call the methods \method{m} and \method{n}
+\name{NetBeans} will try to create code that call the methods \method{m} and \method{n}
of \type{X} by accessing them through \var{c.x}, where \var{c} is a parameter of
type \type{C} that is added the method \method{f} when it is moved. (This is
seldom the desired outcome of this refactoring, but ironically, this ``feature''
-keeps NetBeans from breaking the code in the example from \myref{correctness}.)
+keeps \name{NetBeans} from breaking the code in the example from \myref{correctness}.)
If \var{c.x} for some reason is inaccessible to \type{X}, as in this case, the
-refactoring breaks the code, and it will not compile. NetBeans presents a
+refactoring breaks the code, and it will not compile. \name{NetBeans} presents a
preview of the refactoring outcome, but the preview does not catch it if the IDE
is about break the program.
-The IDEs under investigation seems to have fairly good support for primitive
-refactorings, but what about more complex ones, such as the \refactoring{Extract
-Class}\citing{refactoring}? The \refactoring{Extract Class} refactoring works by
-creating a class, for then to move members to that class and access them from
-the old class via a reference to the new class. \emph{IntelliJ} handles this in
-a fairly good manner, although, in the case of private methods, it leaves unused
+The IDEs under investigation seem to have fairly good support for primitive
+refactorings, but what about more complex ones, such as
+\gloss{extractClass}\citing{refactoring}? \name{IntelliJ} handles this in a
+fairly good manner, although, in the case of private methods, it leaves unused
methods behind. These are methods that delegate to a field with the type of the
-new class, but are not used anywhere. \emph{Eclipse} has added (or withdrawn)
-its own quirk to the Extract Class refactoring, and only allows for
-\emph{fields} to be moved to a new class, \emph{not methods}. This makes it
-effectively only extracting a data structure, and calling it
-\refactoring{Extract Class} is a little misleading. One would often be better
-off with textual extract and paste than using the Extract Class refactoring in
-Eclipse. When it comes to \emph{NetBeans}, it does not even seem to have made an
-attempt on providing this refactoring. (Well, it probably has, but it does not
-show in the IDE.)
-
-\todoin{Visual Studio (C++/C\#), Smalltalk refactoring browser?,
-second refactoring rubicon?}
+new class, but are not used anywhere. \name{Eclipse} has added its own quirk to
+the \refa{Extract Class} refactoring, and only allows for \emph{fields} to be
+moved to a new class, \emph{not methods}. This makes it effectively only
+extracting a data structure, and calling it \refa{Extract Class} is a little
+misleading. One would often be better off with textual extract and paste than
+using the \refa{Extract Class} refactoring in \name{Eclipse}. When it comes to
+\name{NetBeans}, it does not even show an attempt on providing this refactoring.
-\section{The relation to design patterns}\label{relationToDesignPatterns}
+\subsection{The relation to design patterns}\label{relationToDesignPatterns}
-\emph{Refactoring} and \emph{design patterns} have at least one thing in common,
-they are both promoted by advocates of \emph{clean code}\citing{cleanCode} as
-fundamental tools on the road to more maintanable and extendable source code.
+Refactoring and design patterns have at least one thing in common, they are both
+promoted by advocates of \emph{clean code}\citing{cleanCode} as fundamental
+tools on the road to more maintainable and extendable source code.
\begin{quote}
Design patterns help you determine how to reorganize a design, and they can
time and money into a design that inevitably is going to change. By relying on
continuously refactoring a system, its design can be made simpler without
sacrificing flexibility. To be able to fully rely on this approach, it is of
-utter importance to have a reliable suit of tests to lean on. \See{testing} This
+utter importance to have a reliable suit of tests to lean on \see{testing}. This
makes the design process more natural and less characterized by difficult
decisions that has to be made before proceeding in the process, and that is
going to define a project for all of its unforeseeable future.
-\begin{comment}
-
-\section{Classification of refactorings}
-% only interesting refactorings
-% with 2 detailed examples? One for structured and one for intra-method?
-% Is replacing Bubblesort with Quick Sort considered a refactoring?
-
-\subsection{Structural refactorings}
-
-\subsubsection{Primitive refactorings}
-
-% Composing Methods
-\explanation{Extract Method}{You have a code fragment that can be grouped
-together.}{Turn the fragment into a method whose name explains the purpose of
-the method.}
-
-\explanation{Inline Method}{A method's body is just as clear as its name.}{Put
-the method's body into the body of its callers and remove the method.}
-
-\explanation{Inline Temp}{You have a temp that is assigned to once with a simple
-expression, and the temp is getting in the way of other refactorings.}{Replace
-all references to that temp with the expression}
-
-% Moving Features Between Objects
-\explanation{Move Method}{A method is, or will be, using or used by more
-features of another class than the class on which it is defined.}{Create a new
-method with a similar body in the class it uses most. Either turn the old method
-into a simple delegation, or remove it altogether.}
-
-\explanation{Move Field}{A field is, or will be, used by another class more than
-the class on which it is defined}{Create a new field in the target class, and
-change all its users.}
-
-% Organizing Data
-\explanation{Replace Magic Number with Symbolic Constant}{You have a literal
-number with a particular meaning.}{Create a constant, name it after the meaning,
-and replace the number with it.}
-
-\explanation{Encapsulate Field}{There is a public field.}{Make it private and
-provide accessors.}
-
-\explanation{Replace Type Code with Class}{A class has a numeric type code that
-does not affect its behavior.}{Replace the number with a new class.}
-
-\explanation{Replace Type Code with Subclasses}{You have an immutable type code
-that affects the behavior of a class.}{Replace the type code with subclasses.}
+\subsection{The impact on software quality}
-\explanation{Replace Type Code with State/Strategy}{You have a type code that
-affects the behavior of a class, but you cannot use subclassing.}{Replace the
-type code with a state object.}
-
-% Simplifying Conditional Expressions
-\explanation{Consolidate Duplicate Conditional Fragments}{The same fragment of
-code is in all branches of a conditional expression.}{Move it outside of the
-expression.}
-
-\explanation{Remove Control Flag}{You have a variable that is acting as a
-control flag fro a series of boolean expressions.}{Use a break or return
-instead.}
-
-\explanation{Replace Nested Conditional with Guard Clauses}{A method has
-conditional behavior that does not make clear the normal path of
-execution.}{Use guard clauses for all special cases.}
-
-\explanation{Introduce Null Object}{You have repeated checks for a null
-value.}{Replace the null value with a null object.}
-
-\explanation{Introduce Assertion}{A section of code assumes something about the
-state of the program.}{Make the assumption explicit with an assertion.}
-
-% Making Method Calls Simpler
-\explanation{Rename Method}{The name of a method does not reveal its
-purpose.}{Change the name of the method}
-
-\explanation{Add Parameter}{A method needs more information from its
-caller.}{Add a parameter for an object that can pass on this information.}
-
-\explanation{Remove Parameter}{A parameter is no longer used by the method
-body.}{Remove it.}
-
-%\explanation{Parameterize Method}{Several methods do similar things but with
-%different values contained in the method.}{Create one method that uses a
-%parameter for the different values.}
-
-\explanation{Preserve Whole Object}{You are getting several values from an
-object and passing these values as parameters in a method call.}{Send the whole
-object instead.}
-
-\explanation{Remove Setting Method}{A field should be set at creation time and
-never altered.}{Remove any setting method for that field.}
-
-\explanation{Hide Method}{A method is not used by any other class.}{Make the
-method private.}
-
-\explanation{Replace Constructor with Factory Method}{You want to do more than
-simple construction when you create an object}{Replace the constructor with a
-factory method.}
-
-% Dealing with Generalization
-\explanation{Pull Up Field}{Two subclasses have the same field.}{Move the field
-to the superclass.}
-
-\explanation{Pull Up Method}{You have methods with identical results on
-subclasses.}{Move them to the superclass.}
-
-\explanation{Push Down Method}{Behavior on a superclass is relevant only for
-some of its subclasses.}{Move it to those subclasses.}
-
-\explanation{Push Down Field}{A field is used only by some subclasses.}{Move the
-field to those subclasses}
-
-\explanation{Extract Interface}{Several clients use the same subset of a class's
-interface, or two classes have part of their interfaces in common.}{Extract the
-subset into an interface.}
-
-\explanation{Replace Inheritance with Delegation}{A subclass uses only part of a
-superclasses interface or does not want to inherit data.}{Create a field for the
-superclass, adjust methods to delegate to the superclass, and remove the
-subclassing.}
-
-\explanation{Replace Delegation with Inheritance}{You're using delegation and
-are often writing many simple delegations for the entire interface}{Make the
-delegating class a subclass of the delegate.}
-
-\subsubsection{Composite refactorings}
-
-% Composing Methods
-% \explanation{Replace Method with Method Object}{}{}
-
-% Moving Features Between Objects
-\explanation{Extract Class}{You have one class doing work that should be done by
-two}{Create a new class and move the relevant fields and methods from the old
-class into the new class.}
-
-\explanation{Inline Class}{A class isn't doing very much.}{Move all its features
-into another class and delete it.}
-
-\explanation{Hide Delegate}{A client is calling a delegate class of an
-object.}{Create Methods on the server to hide the delegate.}
-
-\explanation{Remove Middle Man}{A class is doing to much simple delegation.}{Get
-the client to call the delegate directly.}
-
-% Organizing Data
-\explanation{Replace Data Value with Object}{You have a data item that needs
-additional data or behavior.}{Turn the data item into an object.}
-
-\explanation{Change Value to Reference}{You have a class with many equal
-instances that you want to replace with a single object.}{Turn the object into a
-reference object.}
-
-\explanation{Encapsulate Collection}{A method returns a collection}{Make it
-return a read-only view and provide add/remove methods.}
-
-% \explanation{Replace Array with Object}{}{}
-
-\explanation{Replace Subclass with Fields}{You have subclasses that vary only in
-methods that return constant data.}{Change the methods to superclass fields and
-eliminate the subclasses.}
-
-% Simplifying Conditional Expressions
-\explanation{Decompose Conditional}{You have a complicated conditional
-(if-then-else) statement.}{Extract methods from the condition, then part, an
-else part.}
-
-\explanation{Consolidate Conditional Expression}{You have a sequence of
-conditional tests with the same result.}{Combine them into a single conditional
-expression and extract it.}
-
-\explanation{Replace Conditional with Polymorphism}{You have a conditional that
-chooses different behavior depending on the type of an object.}{Move each leg
-of the conditional to an overriding method in a subclass. Make the original
-method abstract.}
-
-% Making Method Calls Simpler
-\explanation{Replace Parameter with Method}{An object invokes a method, then
-passes the result as a parameter for a method. The receiver can also invoke this
-method.}{Remove the parameter and let the receiver invoke the method.}
-
-\explanation{Introduce Parameter Object}{You have a group of parameters that
-naturally go together.}{Replace them with an object.}
-
-% Dealing with Generalization
-\explanation{Extract Subclass}{A class has features that are used only in some
-instances.}{Create a subclass for that subset of features.}
-
-\explanation{Extract Superclass}{You have two classes with similar
-features.}{Create a superclass and move the common features to the
-superclass.}
-
-\explanation{Collapse Hierarchy}{A superclass and subclass are not very
-different.}{Merge them together.}
-
-\explanation{Form Template Method}{You have two methods in subclasses that
-perform similar steps in the same order, yet the steps are different.}{Get the
-steps into methods with the same signature, so that the original methods become
-the same. Then you can pull them up.}
-
-
-\subsection{Functional refactorings}
-
-\explanation{Substitute Algorithm}{You want to replace an algorithm with one
-that is clearer.}{Replace the body of the method with the new algorithm.}
-
-\end{comment}
-
-\section{The impact on software quality}
-
-\subsection{What is software quality?}
+\subsubsection{What is software quality?}
The term \emph{software quality} has many meanings. It all depends on the
context we put it in. If we look at it with the eyes of a software developer, it
usually means that the software is easily maintainable and testable, or in other
addition, such things as good documentation could be measured, but this is out
of the scope of this document.)
-\subsection{The impact on performance}
+\subsubsection{The impact on performance}
\begin{quote}
Refactoring certainly will make software go more slowly\footnote{With todays
compiler optimization techniques and performance tuning of e.g. the Java
\noindent So, although an increased amount of method calls could potentially
slow down programs, one should avoid premature optimization and sacrificing good
-design, leaving the performance tuning until after profiling\footnote{For and
- example of a Java profiler, check out VisualVM:
- \url{http://visualvm.java.net/}} the software and having isolated the actual
- problem areas.
-
-\section{Composite refactorings}\label{compositeRefactorings}
-\todo{motivation, examples, manual vs automated?, what about refactoring in a
-very large code base?}
+design, leaving the performance tuning until after \gloss{profiling} the
+software and having isolated the actual problem areas.
+
+\subsection{Composite refactorings}\label{compositeRefactorings}
Generally, when thinking about refactoring, at the mechanical level, there are
essentially two kinds of refactorings. There are the \emph{primitive}
refactorings, and the \emph{composite} refactorings.
\definition{A \emph{primitive refactoring} is a refactoring that cannot be
expressed in terms of other refactorings.}
-\noindent Examples are the \refactoring{Pull Up Field} and \refactoring{Pull Up
+\noindent Examples are the \refa{Pull Up Field} and \refa{Pull Up
Method} refactorings\citing{refactoring}, that move members up in their class
hierarchies.
\definition{A \emph{composite refactoring} is a refactoring that can be
expressed in terms of two or more other refactorings.}
-\noindent An example of a composite refactoring is the \refactoring{Extract
+\noindent An example of a composite refactoring is the \refa{Extract
Superclass} refactoring\citing{refactoring}. In its simplest form, it is composed
of the previously described primitive refactorings, in addition to the
-\refactoring{Pull Up Constructor Body} refactoring\citing{refactoring}. It works
+\refa{Pull Up Constructor Body} refactoring\citing{refactoring}. It works
by creating an abstract superclass that the target class(es) inherits from, then
-by applying \refactoring{Pull Up Field}, \refactoring{Pull Up Method} and
-\refactoring{Pull Up Constructor Body} on the members that are to be members of
-the new superclass. For an overview of the \refactoring{Extract Superclass}
+by applying \refa{Pull Up Field}, \refa{Pull Up Method} and
+\refa{Pull Up Constructor Body} on the members that are to be members of
+the new superclass. If there are multiple classes in play, their interfaces may
+need to be united with the help of some rename refactorings, before extracting
+the superclass. For an overview of the \refa{Extract Superclass}
refactoring, see \myref{fig:extractSuperclass}.
\begin{figure}[h]
\centering
\includegraphics[angle=270,width=\linewidth]{extractSuperclassItalic.pdf}
- \caption{The Extract Superclass refactoring}
+ \caption{The Extract Superclass refactoring, with united interfaces.}
\label{fig:extractSuperclass}
\end{figure}
-\section{Manual vs. automated refactorings}
+\subsection{Manual vs. automated refactorings}
Refactoring is something every programmer does, even if \heshe does not known
the term \emph{refactoring}. Every refinement of source code that does not alter
the program's behavior is a refactoring. For small refactorings, such as
to errors. Getting it right the first time is not easy, considering the method
signature and all the other aspects of the refactoring that has to be in place.
-Take for instance the renaming of classes, methods and fields. For complex
-programs these refactorings are almost impossible to get right. Attacking them
-with textual search and replace, or even regular expressions, will fall short on
-these tasks. Then it is crucial to have proper tool support that can perform
-them automatically. Tools that can parse source code and thus have semantic
-knowledge about which occurrences of which names belong to what construct in the
-program. For even trying to perform one of these complex task manually, one
-would have to be very confident on the existing test suite \see{testing}.
+Consider the renaming of classes, methods and fields. For complex programs these
+refactorings are almost impossible to get right. Attacking them with textual
+search and replace, or even regular expressions, will fall short on these tasks.
+Then it is crucial to have proper tool support that can perform them
+automatically. Tools that can parse source code and thus have semantic knowledge
+about which occurrences of which names belong to what construct in the program.
+For even trying to perform one of these complex task manually, one would have to
+be very confident on the existing test suite \see{testing}.
-\section{Correctness of refactorings}\label{correctness}
+\subsection{Correctness of refactorings}\label{correctness}
For automated refactorings to be truly useful, they must show a high degree of
-behavior preservation. This last sentence might seem obvious, but there are
-examples of refactorings in existing tools that break programs. I will now
-present an example of an \ExtractMethod refactoring followed by a \MoveMethod
-refactoring that breaks a program in both the \emph{Eclipse} and \emph{IntelliJ}
-IDEs\footnote{The NetBeans IDE handles this particular situation without
- altering the program's beavior, mainly because its Move Method refactoring
- implementation is a bit flawed in other ways \see{toolSupport}.}. The
- following piece of code shows the target for the composed refactoring:
-
-\begin{minted}[linenos,samepage]{java}
+behavior preservation. This last sentence might seem obvious, but there are
+examples of refactorings in existing tools that break programs. In an ideal
+world, every automated refactoring would be ``complete'', in the sense that it
+would never break a program. In an ideal world, every program would also be free
+from bugs. In modern IDEs the implemented automated refactorings are working for
+\emph{most} cases, that is enough for making them useful.
+
+I will now present an example of a \emph{corner case} where a program breaks
+when a refactoring is applied. The example shows an \ExtractMethod refactoring
+followed by a \MoveMethod refactoring that breaks a program in both the
+\name{Eclipse} and \name{IntelliJ} IDEs\footnote{The \name{NetBeans} IDE handles this
+ particular situation without altering the program's behavior, mainly because
+ its \refa{Move Method} refactoring implementation is a bit flawed in other ways
+ \see{toolSupport}.}. The target and the destination for the composed
+ refactoring is shown in \myref{lst:correctnessExtractAndMove}. Note that the
+ method \method{m(C c)} of class \type{X} assigns to the field \var{x} of the
+ argument \var{c} that has type \type{C}.
+
+\begin{listing}[h]
+\begin{multicols}{2}
+\begin{minted}[linenos,frame=topline,label={Refactoring
+ target},framesep=\mintedframesep]{java}
public class C {
- public X x = new X();
+ public X x = new X();
- public void f() {
- x.m(this);
- x.n();
- }
+ public void f() {
+ x.m(this);
+ // Not the same x
+ x.n();
+ }
}
\end{minted}
-\noindent The next piece of code shows the destination of the refactoring. Note
-that the method \method{m(C c)} of class \type{C} assigns to the field \var{x}
-of the argument \var{c} that has type \type{C}:
+\columnbreak
-\begin{minted}[samepage]{java}
+\begin{minted}[frame=topline,label={Method
+ destination},framesep=\mintedframesep]{java}
public class X {
- public void m(C c) {
- c.x = new X();
- }
- public void n() {}
+ public void m(C c) {
+ c.x = new X();
+ // If m is called from
+ // c, then c.x no longer
+ // equals 'this'
+ }
+ public void n() {}
}
\end{minted}
+\end{multicols}
+\caption{The target and the destination for the composition of the Extract
+Method and \refa{Move Method} refactorings.}
+\label{lst:correctnessExtractAndMove}
+\end{listing}
-The refactoring sequence works by extracting line 5 and 6 from the original
+
+The refactoring sequence works by extracting line 6 through 8 from the original
class \type{C} into a method \method{f} with the statements from those lines as
-its method body. The method is then moved to the class \type{X}. The result is
-shown in the following two pieces of code:
+its method body (but with the comment left out, since it will no longer hold any
+meaning). The method is then moved to the class \type{X}. The result is shown
+in \myref{lst:correctnessExtractAndMoveResult}.
+
+Before the refactoring, the methods \method{m} and \method{n} of class \type{X}
+are called on different object instances (see line 6 and 8 of the original class
+\type{C} in \cref{lst:correctnessExtractAndMove}). After the refactoring, they
+are called on the same object, and the statement on line
+3 of class \type{X} (in \cref{lst:correctnessExtractAndMoveResult}) no longer
+ has the desired effect in our example. The method \method{f} of class \type{C}
+ is now calling the method \method{f} of class \type{X} (see line 5 of class
+ \type{C} in \cref{lst:correctnessExtractAndMoveResult}), and the program now
+ behaves different than before.
-\begin{minted}[linenos,samepage]{java}
+\begin{listing}[h]
+\begin{multicols}{2}
+\begin{minted}[linenos]{java}
public class C {
public X x = new X();
}
\end{minted}
-\begin{minted}[linenos,samepage]{java}
+\columnbreak
+
+\begin{minted}[linenos]{java}
public class X {
public void m(C c) {
c.x = new X();
}
public void n() {}
+ // Extracted and
+ // moved method
public void f(C c) {
m(c);
n();
}
}
\end{minted}
-
-After the refactoring, the method \method{f} of class \type{C} is calling the
-method \method{f} of class \type{X}, and the program now behaves different than
-before. (See line 5 of the version of class \type{C} after the refactoring.)
-Before the refactoring, the methods \method{m} and \method{n} of class \type{X}
-are called on different object instances (see line 5 and 6 of the original class
-\type{C}). After, they are called on the same object, and the statement on line
-3 of class \type{X} (the version after the refactoring) no longer have any
- effect in our example.
+\end{multicols}
+\caption{The result of the composed refactoring.}
+\label{lst:correctnessExtractAndMoveResult}
+\end{listing}
The bug introduced in the previous example is of such a nature\footnote{Caused
by aliasing. See \url{https://en.wikipedia.org/wiki/Aliasing_(computing)}}
tests. It does not generate compilation errors, and will thus only result in
a runtime error or corrupted data, which might be hard to detect.
-\section{Refactoring and the importance of testing}\label{testing}
+\subsection{Refactoring and the importance of testing}\label{testing}
\begin{quote}
If you want to refactor, the essential precondition is having solid
tests.\citing{refactoring}
kind of errors does not reveal themselves.
Unit testing is not a way to \emph{prove} that a program is correct, but it is a
-way to make you confindent that it \emph{probably} works as desired. In the
-context of test driven development (commonly known as TDD), the tests are even a
+way to make you confident that it \emph{probably} works as desired. In the
+context of test-driven development (commonly known as TDD), the tests are even a
way to define how the program is \emph{supposed} to work. It is then, by
definition, working if the tests are passing.
be risk-free to perform refactorings on it. This is why automated tests and
refactoring are such a great match.
-\subsection{Testing the code from correctness section}
+\subsubsection{Testing the code from correctness section}
The worst thing that can happen when refactoring is to introduce changes to the
behavior of a program, as in the example on \myref{correctness}. This example
may be trivial, but the essence is clear. The only problem with the example is
that it is not clear how to create automated tests for it, without changing it
in intrusive ways.
-Unit tests, as they are known from the different xUnit frameworks around, are
+Unit tests, as they are known from the different \glosspl{xUnit} around, are
only suitable to test the \emph{result} of isolated operations. They can not
easily (if at all) observe the \emph{history} of a program.
This problem is still open.
-\todoin{Write?}
\begin{comment}
Assuming a sequential (non-concurrent) program:
%\end{minted}
\end{comment}
-\section{The project}
-The aim of this master project will be to investigate the relationship between a
-composite refactoring composed of the \ExtractMethod and \MoveMethod
-refactorings, and its impact on one or more software metrics.
+
+\section{The Project}
+In this section we look at the work that shall be done for this project, its
+building stones and some of the methodologies used.
+
+\subsection{Project description}
+The aim of this master's project will be to explore the relationship between the
+\ExtractMethod and the \MoveMethod refactorings. This will be done by composing
+the two into a composite refactoring. The refactoring will be called the
+\ExtractAndMoveMethod refactoring.
+
+The two primitive \ExtractMethod and \MoveMethod refactorings must already be
+implemented in a tool, so the \ExtractAndMoveMethod refactoring is going to be
+built on top of those.
The composition of the \ExtractMethod and \MoveMethod refactorings springs
naturally out of the need to move procedures closer to the data they manipulate.
This composed refactoring is not well described in the literature, but it is
implemented in at least one tool called
-\emph{CodeRush}\footnote{\url{https://help.devexpress.com/\#CodeRush/CustomDocument3519}},
-that is an extension for \emph{MS Visual
+\name{CodeRush}\footnote{\url{https://help.devexpress.com/\#CodeRush/CustomDocument3519}},
+that is an extension for \name{MS Visual
Studio}\footnote{\url{http://www.visualstudio.com/}}. In CodeRush it is called
-\emph{Extract Method to
+\refa{Extract Method to
Type}\footnote{\url{https://help.devexpress.com/\#CodeRush/CustomDocument6710}},
-but I choose to call it \ExtractAndMoveMethod, since I feel it better
+but I choose to call it \ExtractAndMoveMethod, since I feel this better
communicates which primitive refactorings it is composed of.
-For the metrics, I will at least measure the \emph{Coupling between object
-classes} (CBO) metric that is described by Chidamber and Kemerer in their
-article \emph{A Metrics Suite for Object Oriented
-Design}\citing{metricsSuite1994}.
-
-The project will then consist in implementing the \ExtractAndMoveMethod
-refactoring, as well as executing it over a larger code base. Then the effect of
-the change must be measured by calculating the chosen software metrics both
-before and after the execution. To be able to execute the refactoring
-automatically I have to make it analyze code to determine the best selections to
-extract into new methods.
+The project will consist of implementing the \ExtractAndMoveMethod refactoring,
+as well as executing it over a larger code base, as a case study. To be able to
+execute the refactoring automatically, I have to make it analyze code to
+determine the best selections to extract into new methods.
+\subsection{The premises}
+Before we can start manipulating source code and write a tool for doing so, we
+need to decide on a programming language for the code we are going to
+manipulate. Also, since we do not want to start from scratch by implementing
+primitive refactorings ourselves, we need to choose an existing tool that
+provides the needed refactorings. In addition to be able to perform changes, we
+need a framework for analyzing source code for the language we select.
-%\part{The project}
-%\chapter{Planning the project}
-%\part{Conclusion}
-%\chapter{Results}
-
-
-
-\chapter{The Project}
-
-\section{The problem statement}
-\todoin{write/move}
-
-\section{Choosing the target language}
+\subsubsection{Choosing the target language}
Choosing which programming language the code that shall be manipulated shall be
written in, is not a very difficult task. We choose to limit the possible
languages to the object-oriented programming languages, since most of the
object-oriented programming. In addition, the language must have existing tool
support for refactoring.
-The \emph{Java} programming language\footnote{\url{https://www.java.com/}} is
+The \name{Java} programming language\footnote{\url{https://www.java.com/}} is
the dominating language when it comes to example code in the literature of
refactoring, and is thus a natural choice. Java is perhaps, currently the most
-influential programming language in the world, with its \emph{Java Virtual
+influential programming language in the world, with its \name{Java Virtual
Machine} that runs on all of the most popular architectures and also supports
-dozens of other programming languages\footnote{They compile to java bytecode.},
-with \emph{Scala}, \emph{Clojure} and \emph{Groovy} as the most prominent ones.
+dozens of other programming languages\footnote{They compile to Java bytecode.},
+with \name{Scala}, \name{Clojure} and \name{Groovy} as the most prominent ones.
Java is currently the language that every other programming language is compared
against. It is also the primary programming language for the author of this
thesis.
-\section{Choosing the tools}
-When choosing a tool for manipulating Java, there are certain criterias that
+\subsubsection{Choosing the tools}
+When choosing a tool for manipulating Java, there are certain criteria that
have to be met. First of all, the tool should have some existing refactoring
support that this thesis can build upon. Secondly it should provide some kind of
framework for parsing and analyzing Java source code. Third, it should itself be
the existing refactorings that is contained in the tool, and also because open
source projects hold value in them selves. Another important aspect to consider
is that open source projects of a certain size, usually has large communities of
-people connected to them, that are commited to answering questions regarding the
-use and misuse of the products, that to a large degree is made by the cummunity
+people connected to them, that are committed to answering questions regarding the
+use and misuse of the products, that to a large degree is made by the community
itself.
-There is a certain class of tools that meet these criterias, namely the class of
+There is a certain class of tools that meet these criteria, namely the class of
\emph{IDEs}\footnote{\emph{Integrated Development Environment}}. These are
-proagrams that is ment to support the whole production cycle of a cumputer
+programs that is meant to support the whole production cycle of a computer
program, and the most popular IDEs that support Java, generally have quite good
refactoring support.
-The main contenders for this thesis is the \emph{Eclipse IDE}, with the
-\emph{Java development tools} (JDT), the \emph{IntelliJ IDEA Community Edition}
-and the \emph{NetBeans IDE}. \See{toolSupport} Eclipse and NetBeans are both
-free, open source and community driven, while the IntelliJ IDEA has an open
-sourced community edition that is free of charge, but also offer an
-\emph{Ultimate Edition} with an extended set of features, at additional cost.
-All three IDEs supports adding plugins to extend their functionality and tools
-that can be used to parse and analyze Java source code. But one of the IDEs
-stand out as a favorite, and that is the \emph{Eclipse IDE}. This is the most
-popular\citing{javaReport2011} among them and seems to be de facto standard IDE
-for Java development regardless of platform.
-
-\section{Organizing the project}
-All the parts of this master project is under version control with
-\emph{Git}\footnote{\url{http://git-scm.com/}}.
-
-The software written is organized as some Eclipse plugins. Writing a plugin is
-the natural way to utilize the API of Eclipse. This also makes it possible to
-provide a user interface to manually run operations on selections in program
-source code or whole projects/packages.
+The main contenders for this thesis is the \name{Eclipse IDE}, with the
+\name{Java development tools} (JDT), the \name{IntelliJ IDEA Community Edition}
+and the \name{NetBeans IDE} \see{toolSupport}. \name{Eclipse} and
+\name{NetBeans} are both free, open source and community driven, while the
+\name{IntelliJ IDEA} has an open sourced community edition that is free of
+charge, but also offer an \name{Ultimate Edition} with an extended set of
+features, at additional cost. All three IDEs supports adding plugins to extend
+their functionality and tools that can be used to parse and analyze Java source
+code. But one of the IDEs stand out as a favorite, and that is the \name{Eclipse
+IDE}. This is the most popular\citing{javaReport2011} among them and seems to be
+de facto standard IDE for Java development regardless of platform.
+
+\subsection{The primitive refactorings}
+The refactorings presented here are the primitive refactorings used in this
+project. They are the abstract building blocks used by the \ExtractAndMoveMethod
+refactoring.
+
+\paragraph{The Extract Method refactoring}
+The \refa{Extract Method} refactoring is used to extract a fragment of code
+from its context and into a new method. A call to the new method is inlined
+where the fragment was before. It is used to break code into logical units, with
+names that explain their purpose.
+
+An example of an \ExtractMethod refactoring is shown in
+\myref{lst:extractMethodRefactoring}. It shows a method containing calls to the
+methods \method{foo} and \method{bar} of a type \type{X}. These statements are
+then extracted into the new method \method{fooBar}.
-When writing a plugin in Eclipse, one has access to resources such as the
-current workspace, the open editor and the current selection.
+\begin{listing}[h]
+ \begin{multicols}{2}
+ \begin{minted}[samepage,frame=topline,label={Before},framesep=\mintedframesep]{java}
+ class C {
+ void method() {
+ X x = new X();
+ x.foo(); x.bar();
+ }
+ }
+ \end{minted}
-\section{Continuous integration}
-The continuous integration server
-\emph{Jenkins}\footnote{\url{http://jenkins-ci.org/}} has been set up for the
-project\footnote{A work mostly done by the supervisor.}. It is used as a way to
-run tests and perform code coverage analysis.
+ \columnbreak
-To be able to build the Eclipse plugins and run tests for them with Jenkins, the
-component assembly project
-\emph{Buckminster}\footnote{\url{http://www.eclipse.org/buckminster/}} is used,
-through its plugin for Jenkins. Buckminster provides for a way to specify the
-resources needed for building a project and where and how to find them.
-Buckminster also handles the setup of a target environment to run the tests in.
-All this is needed because the code to build depends on an Eclipse installation
-with various plugins.
+ \begin{minted}[samepage,frame=topline,label={After},framesep=\mintedframesep]{java}
+ class C {
+ void method() {
+ X x = new X();
+ fooBar(x);
+ }
+ void fooBar(X x) {
+ x.foo(); x.bar();
+ }
+ }
+ \end{minted}
+ \end{multicols}
+ \caption{An example of an \ExtractMethod refactoring.}
+ \label{lst:extractMethodRefactoring}
+\end{listing}
-\subsection{Problems with AspectJ}
-The Buckminster build worked fine until introducing AspectJ into the project.
-When building projects using AspectJ, there are some additional steps that needs
-to be performed. First of all, the aspects themselves must be compiled. Then the
-aspects needs to be woven with the classes they affect. This demands a process
-that does multiple passes over the source code.
+\paragraph{The Move Method refactoring}
+The \refa{Move Method} refactoring is used to move a method from one class to
+another. This can be appropriate if the method is using more features of another
+class than of the class which it is currently defined.
-When using AspectJ with Eclipse, the specialized compilation and the weaving can
-be handled by the \emph{AspectJ Development
-Tools}\footnote{\url{https://www.eclipse.org/ajdt/}}. This works all fine, but
-it complicates things when trying to build a project depending on Eclipse
-plugins outside of Eclipse. There is supposed to be a way to specify a compiler
-adapter for javac, together with the file extensions for the file types it shall
-operate. The AspectJ compiler adapter is called
-\typewithref{org.aspectj.tools.ant.taskdefs}{Ajc11CompilerAdapter}, and it works
-with files that has the extensions \code{*.java} and \code{*.aj}. I tried to
-setup this in the build properties file for the project containing the aspects,
-but to no avail. The project containing the aspects does not seem to be built at
-all, and the projects that depends on it complains that they cannot find certain
-classes.
+\Myref{lst:moveMethodRefactoring} shows an example of this refactoring. Here a
+method \method{fooBar} is moved from the class \type{C} to the class \type{X}.
-I then managed to write an \emph{Ant}\footnote{\url{https://ant.apache.org/}}
-build file that utilizes the AspectJ compiler adapter, for the
-\code{no.uio.ifi.refaktor} plugin. The problem was then that it could no longer
-take advantage of the environment set up by Buckminster. The solution to this
-particular problem was of a ``hacky'' nature. It involves exporting the plugin
-dependencies for the project to an Ant build file, and copy the exported path
-into the existing build script. But then the Ant script needs to know where the
-local Eclipse installation is located. This is no problem when building on a
-local machine, but to utilize the setup done by Buckminster is a problem still
-unsolved. To get the classpath for the build setup correctly, and here comes the
-most ``hacky'' part of the solution, the Ant script has a target for copying the
-classpath elements into a directory relative to the project directory and
-checking it into Git. When no \code{ECLIPSE\_HOME} property is set while running
-Ant, the script uses the copied plugins instead of the ones provided by the
-Eclipse installation when building the project. This obviously creates some
-problems with maintaining the list of dependencies in the Ant file, as well as
-remembering to copy the plugins every time the list of dependencies change.
+\begin{listing}[h]
+ \begin{multicols}{2}
+ \begin{minted}[samepage,frame=topline,label={Before},framesep=\mintedframesep]{java}
+ class C {
+ void method() {
+ X x = new X();
+ fooBar(x);
+ }
+ void fooBar(X x) {
+ x.foo(); x.bar();
+ }
+ }
+
+ class X {
+ void foo(){/*...*/}
+ void bar(){/*...*/}
+ }
+ \end{minted}
-The Ant script described above is run by Jenkins before the Buckminster setup
-and build. When setup like this, the Buckminster build succeeds for the projects
-not using AspectJ, and the tests are run as normal. This is all good, but it
-feels a little scary, since the reason for Buckminster not working with AspectJ
-is still unknown.
+ \columnbreak
-The problems with building with AspectJ on the Jenkins server lasted for a
-while, before they were solved. This is reflected in the ``Test Result Trend''
-and ``Code Coverage Trend'' reported by Jenkins.
+ \begin{minted}[samepage,frame=topline,label={After},framesep=\mintedframesep]{java}
+ class C {
+ void method() {
+ X x = new X();
+ x.fooBar();
+ }
+ }
+
+ class X {
+ void fooBar() {
+ foo(); bar();
+ }
+ void foo(){/*...*/}
+ void bar(){/*...*/}
+ }
+ \end{minted}
+ \end{multicols}
+ \caption{An example of a \MoveMethod refactoring.}
+ \label{lst:moveMethodRefactoring}
+\end{listing}
+
+\subsection{The Extract and Move Method refactoring}
+The \ExtractAndMoveMethod refactoring is a composite refactoring composed of the
+primitive \ExtractMethod and \MoveMethod refactorings. The effect of this
+refactoring on source code is the same as when extracting a method and moving it
+to another class. Conceptually, this is done without an intermediate step. In
+practice, as we shall see later, an intermediate step may be necessary.
+
+An example of this composite refactoring is shown in
+\myref{lst:extractAndMoveMethodRefactoring}. The example joins the examples from
+\cref{lst:extractMethodRefactoring} and \cref{lst:moveMethodRefactoring}. This
+means that the selection consisting of the consecutive calls to the methods
+\method{foo} and \method{bar}, is extracted into a new method \method{fooBar}
+located in the class \type{X}.
+
+\begin{listing}[h]
+ \begin{multicols}{2}
+ \begin{minted}[samepage,frame=topline,label={Before},framesep=\mintedframesep]{java}
+ class C {
+ void method() {
+ X x = new X();
+ x.foo(); x.bar();
+ }
+ }
+
+ class X {
+ void foo(){/*...*/}
+ void bar(){/*...*/}
+ }
+ \end{minted}
+
+ \columnbreak
+
+ \begin{minted}[samepage,frame=topline,label={After},framesep=\mintedframesep]{java}
+ class C {
+ void method() {
+ X x = new X();
+ x.fooBar();
+ }
+ }
+
+ class X {
+ void fooBar() {
+ foo(); bar();
+ }
+ void foo(){/*...*/}
+ void bar(){/*...*/}
+ }
+ \end{minted}
+ \end{multicols}
+ \caption{An example of the \ExtractAndMoveMethod refactoring.}
+ \label{lst:extractAndMoveMethodRefactoring}
+\end{listing}
+
+\subsection{Research questions}
+The main question that I seek an answer to in this thesis is:
+
+\begin{quote}
+ Is it possible to automate the analysis and execution of the
+ \ExtractAndMoveMethod refactoring, and do so for all of the code of a larger
+ project?
+\end{quote}
+
+\noindent The secondary questions will then be:
+
+\paragraph{Can we do this efficiently?} Can we automate the analysis and
+execution of the refactoring so it can be run in a reasonable amount of time?
+And what does \emph{reasonable} mean in this context?
+
+And, assuming the refactoring does in fact improve the quality of source code:
+
+\paragraph{How can the automation of the refactoring be helpful?} What is the
+usefulness of the refactoring in a software development setting? In what parts
+of the development process can the refactoring play a role?
+
+\subsection{Methodology}
+
+\subsubsection{Evolutionary design}
+In the programming work for this project, it have tried to use a design strategy
+called evolutionary design, also known as continuous or incremental
+design\citing{wiki_continuous_2014}. It is a software design strategy
+advocated by the Extreme Programming community. The essence of the strategy is
+that you should let the design of your program evolve naturally as your
+requirements change. This is seen in contrast with up-front design, where
+design decisions are made early in the process.
+
+The motivation behind evolutionary design is to keep the design of software as
+simple as possible. This means not introducing unneeded functionality into a
+program. You should defer introducing flexibility into your software, until it
+is needed to be able to add functionality in a clean way.
+
+Holding up design decisions, implies that the time will eventually come when
+decisions have to be made. The flexibility of the design then relies on the
+programmer's abilities to perform the necessary refactoring, and \his confidence
+in those abilities. From my experience working on this project, I can say that
+this confidence is greatly enhanced by having automated tests to rely on
+\see{tdd}.
+
+The choice of going for evolutionary design developed naturally. As Fowler
+points out in his article \tit{Is Design Dead?}, evolutionary design much
+resembles the ``code and fix'' development strategy\citing{fowler_design_2004}.
+A strategy that most of us have practiced in school. This was also the case when
+I first started this work. I had to learn the inner workings of Eclipse and its
+refactoring-related plugins. That meant a lot of fumbling around with code I did
+not know, in a trial and error fashion. Eventually I started writing tests for
+my code, and my design began to evolve.
+
+\subsubsection{Test-driven development}\label{tdd}
+As mentioned before, the project started out as a classic code and fix
+developmen process. My focus was aimed at getting something to work, rather than
+doing so according to best practice. This resulted in a project that got out of
+its starting blocks, but it was not accompanied by any tests. Hence it was soon
+difficult to make any code changes with the confidence that the program was
+still correct afterwards (assuming it was so before changing it). I always knew
+that I had to introduce some tests at one point, but this experience accelerated
+the process of leading me onto the path of testing.
+
+I then wrote tests for the core functionality of the plugin, and thus gained
+more confidence in the correctness of my code. I could now perform quite drastic
+changes without ``wetting my pants``. After this, nearly all of the semantic
+changes done to the business logic of the project, or the addition of new
+functionality, was made in a test-driven manner. This means that before
+performing any changes, I would define the desired functionality through a set
+of tests. I would then run the tests to check that they were run and that they
+did not pass. Then I would do any code changes necessary to make the tests
+pass. The definition of how the program is supposed to operate is then captured
+by the tests. However, this does not prove the correctness of the analysis
+leading to the test definitions.
+
+\subsubsection{Continuous integration}
+\todoin{???}
+
+\section{Related Work}
+
+\subsection{Safer refactorings}
+\todoin{write}
+
+\subsection{The compositional paradigm of refactoring}
+This paradigm builds upon the observation of Vakilian et
+al.\citing{vakilian2012}, that of the many automated refactorings existing in
+modern IDEs, the simplest ones are dominating the usage statistics. The report
+mainly focuses on \name{Eclipse} as the tool under investigation.
+
+The paradigm is described almost as the opposite of automated composition of
+refactorings \see{compositeRefactorings}. It works by providing the programmer
+with easily accessible primitive refactorings. These refactorings shall be
+accessed via keyboard shortcuts or quick-assist menus\footnote{Think
+quick-assist with Ctrl+1 in \name{Eclipse}} and be promptly executed, opposed to in the
+currently dominating wizard-based refactoring paradigm. They are meant to
+stimulate composing smaller refactorings into more complex changes, rather than
+doing a large upfront configuration of a wizard-based refactoring, before
+previewing and executing it. The compositional paradigm of refactoring is
+supposed to give control back to the programmer, by supporting \himher with an
+option of performing small rapid changes instead of large changes with a lesser
+degree of control. The report authors hope this will lead to fewer unsuccessful
+refactorings. It also could lower the bar for understanding the steps of a
+larger composite refactoring and thus also help in figuring out what goes wrong
+if one should choose to op in on a wizard-based refactoring.
+
+Vakilian and his associates have performed a survey of the effectiveness of the
+compositional paradigm versus the wizard-based one. They claim to have found
+evidence of that the \emph{compositional paradigm} outperforms the
+\emph{wizard-based}. It does so by reducing automation, which seem
+counterintuitive. Therefore they ask the question ``What is an appropriate level
+of automation?'', and thus questions what they feel is a rush toward more
+automation in the software engineering community.
+
+
+
+\chapter{The search-based Extract and Move Method refactoring}
+In this chapter I will delve into the workings of the search-based
+\ExtractAndMoveMethod refactoring. We will see the choices it must make along
+the way and why it chooses a text selection as a candidate for refactoring or
+not.
+
+After defining some concepts, I will introduce an example that will be used
+throughout the chapter to illustrate how the refactoring works in some simple
+situations.
+
+\section{The inputs to the refactoring}
+For executing an \ExtractAndMoveMethod refactoring, there are two simple
+requirements. The first thing the refactoring needs is a text selection, telling
+it what to extract. Its second requirement is a target for the subsequent move
+operation.
+
+The extracted method must be called instead of the selection that makes up its
+body. Also, the method call has to be performed via a variable, since the method
+is not static. Therefore, the move target must be a variable in the scope of the
+extracted selection. The actual new location for the extracted method will be
+the class representing the type of the move target variable. But, since the
+method also must be called through a variable, it makes sense to define the move
+target to be either a local variable or a field in the scope of the text
+selection.
+
+\section{Defining a text selection}
+A text selection, in our context, is very similar to what you think of when
+selecting a bit of text in your editor or other text processing tool with your
+mouse or keyboard. It is an abstract construct that is meant to capture which
+specific portion of text we are about to deal with.
+
+To be able to clearly reason about a text selection done to a portion of text in
+a computer file, that consist of pure text, we put up the following definition.
+
+\definition{A \emph{text selection} in a text file is defined by two
+non-negative integers, in addition to a reference to the file itself. The first
+integer is an offset into the file, while the second reference is the length of
+the text selection.}
+
+This means that the selected text consist of a number of characters equal to the
+length of the selection, where the first character is found at the specified
+offset.
+
+\section{Where we look for text selections}
+
+\subsection{Text selections are found in methods}
+The text selections we are interested in are those that surrounds program
+statements. Therefore, the place we look for selections that can form candidates
+for an execution of the \ExtractAndMoveMethod refactoring, is within the body of
+a single method.
+
+\paragraph{On ignoring static methods}
+In this project we are not analyzing static methods for candidates to the
+\ExtractAndMoveMethod refactoring. The reason for this is that in the cases
+where we want to perform the refactoring for a selection within a static method,
+the first step is to extract the selection into a new method. Hence this method
+also become static, since it must be possible to call it from a static context.
+It would then be difficult to move the method to another class, make it
+non-static and calling it through a variable. To avoid these obstacles, we
+simply ignore static methods.
+
+\begin{listing}[htb]
+\def\charwidth{5.8pt}
+\def\indent{2*\charwidth}
+\def\lineheight{\baselineskip}
+\def\mintedtop{2*\lineheight+5.8pt}
+
+\begin{tikzpicture}[overlay, yscale=-1, xshift=3.8pt+\charwidth*31]
+ \tikzstyle{overlaybox}=[fill=lightgray,opacity=0.2]
+ % Level 1
+ \draw[overlaybox] (\indent,\mintedtop+\lineheight*4) rectangle
+ +(23*\charwidth,17*\lineheight);
+
+ % Level 2
+ \draw[overlaybox] (2*\indent,\mintedtop+5*\lineheight) rectangle
+ +(15*\charwidth,3*\lineheight);
+ \draw[overlaybox] (2*\indent,\mintedtop+15*\lineheight) rectangle
+ +(15*\charwidth,3*\lineheight);
+ \draw[overlaybox] (2*\indent,\mintedtop+19*\lineheight) rectangle
+ +(15*\charwidth,\lineheight);
+\end{tikzpicture}
+ \begin{multicols}{2}
+ \begin{minted}[linenos,frame=topline,label=Clean,framesep=\mintedframesep]{java}
+class C {
+ A a; B b; boolean bool;
+
+ void method(int val) {
+ if (bool) {
+ a.foo();
+ a = new A();
+ a.bar();
+ }
+
+ a.foo();
+ a.bar();
+
+ switch (val) {
+ case 1:
+ b.a.foo();
+ b.a.bar();
+ break;
+ default:
+ a.foo();
+ }
+ }
+}
+\end{minted}
+
+\columnbreak
+
+\begin{minted}[frame=topline,label={With statement
+ sequences},framesep=\mintedframesep]{java}
+class C {
+ A a; B b; boolean bool;
+
+ void method(int val) {
+ if (bool) {
+ a.foo();
+ a = new A();
+ a.bar();
+ }
+
+ a.foo();
+ a.bar();
+
+ switch (val) {
+ case 1:
+ b.a.foo();
+ b.a.bar();
+ break;
+ default:
+ a.foo();
+ }
+ }
+}
+\end{minted}
+
+ \end{multicols}
+\caption{Classes \type{A} and \type{B} are both public. The methods
+\method{foo} and \method{bar} are public members of class \type{A}.}
+\label{lst:grandExample}
+\end{listing}
+
+\subsection{The possible text selections of a method body}
+\todoin{dummy todo}
+The number of possible text selections that can be made from the text in a
+method body, are equal to all the sub-sequences of characters within it. For our
+purposes, analyzing program source code, we must define what it means for a text
+selection to be valid.
+
+\definition{A \emph{valid text selection} is a text selection that contains all
+of one or more consecutive program statements.}
+
+For a sequence of statements, the text selections that can be made from it, are
+equal to all its sub-sequences. \Myref{lst:textSelectionsExample} show an
+example of all the text selections that can be made from the code in
+\myref{lst:grandExample}, lines 16-18. For convenience and the clarity of this
+example, the text selections are represented as tuples with the start and end
+line of all selections: $\{(16), (17), (18), (16,17), (16,18), (17,18)\}$.
+
+\begin{listing}[htb]
+\def\charwidth{5.7pt}
+\def\indent{4*\charwidth}
+\def\lineheight{\baselineskip}
+\def\mintedtop{\lineheight-1pt}
+
+\begin{tikzpicture}[overlay, yscale=-1]
+ \tikzstyle{overlaybox}=[fill=lightgray,opacity=0.2]
+
+ % First statement
+ \draw[overlaybox] (2*\charwidth,\mintedtop) rectangle
+ +(16*\charwidth,\lineheight);
+
+ % Second statement
+ \draw[overlaybox] (2*\charwidth,\mintedtop+\lineheight) rectangle
+ +(16*\charwidth,\lineheight);
+
+ % Third statement
+ \draw[overlaybox] (2*\charwidth,\mintedtop+2*\lineheight) rectangle
+ +(16*\charwidth,\lineheight);
+
+ \draw[overlaybox] (\indent-3*\charwidth,\mintedtop) rectangle
+ +(18*\charwidth,2*\lineheight);
+
+ \draw[overlaybox] (3*\charwidth,\mintedtop+\lineheight) rectangle
+ +(14*\charwidth,2*\lineheight);
+
+ % All
+ \draw[overlaybox] (\indent,\mintedtop) rectangle
+ +(12*\charwidth,3*\lineheight);
+\end{tikzpicture}
+% indent should be 5 spaces
+\begin{minted}[linenos,firstnumber=16]{java}
+ b.a.foo();
+ b.a.bar();
+ break;
+\end{minted}
+\caption{Example of how the text selections generator would generate text
+ selections based on a lists of statements. Each highlighted rectangle
+represents a text selection.}
+\label{lst:textSelectionsExample}
+\end{listing}
+
+Each nesting level of a method body can have many such sequences of statements.
+The outermost nesting level has one such sequence, and each branch contains
+their own sequence of statements. \Myref{lst:grandExample} has a version of some
+code where all such sequences of statements are highlighted for a method body.
+
+To complete our example of possible text selections, I will now list all
+possible text selections for the method in \myref{lst:grandExample}, by nesting
+level. There are 23 of them in total.
+
+\begin{description}
+ \item[Level 1 (10 selections)] \hfill \\
+ $\{(5,9), (11), (12), (14,21), (5,11), (5,12), (5,21), (11,12),
+ (11,21), \\(12,21)\}$
+
+ \item[Level 2 (13 selections)] \hfill \\
+ $\{(6), (7), (8), (6,7), (6,8), (7,8), (16), (17), (18), (16,17), (16,18), \\
+ (17,18), (20)\}$
+\end{description}
+
+\subsubsection{The complexity}\label{sec:complexity}
+The complexity of how many text selections that needs to be analyzed for a body
+of in total $n$ statements, is bounded by $O(n^2)$. A body of statements is here
+all the statements in all nesting levels of a sequence of statements. A method
+body (or a block) is a body of statements. To prove that the complexity is
+bounded by $O(n^2)$, I present a couple of theorems and proves them.
+
+\begin{theorem}
+The number of text selections that need to be analyzed for each list of
+statements of length $n$, is exactly
+
+\begin{equation*}
+ \sum_{i=1}^{n} i = \frac{n(n+1)}{2}
+ \label{eq:complexityStatementList}
+\end{equation*}
+\label{thm:numberOfTextSelection}
+\end{theorem}
+
+\begin{proof}
+ For $n=1$ this is trivial: $\frac{1(1+1)}{2} = \frac{2}{2} = 1$. One statement
+ equals one selection.
+
+ For $n=2$, you get one text selection for the first statement, one selection
+ for the second statement, and one selection for the two of them combined.
+ This equals three selections. $\frac{2(2+1)}{2} = \frac{6}{2} = 3$.
+
+ For $n=3$, you get 3 selections for the two first statements, as in the case
+ where $n=2$. In addition you get one selection for the third statement itself,
+ and two more statements for the combinations of it with the two previous
+ statements. This equals six selections. $\frac{3(3+1)}{2} = \frac{12}{2} = 6$.
+
+ Assume that for $n=k$ there exists $\frac{k(k+1)}{2}$ text selections. Then we
+ want to add selections for another statement, following the previous $k$
+ statements. So, for $n=k+1$, we get one additional selection for the statement
+ itself. Then we get one selection for each pair of the new selection and the
+ previous $k$ statements. So the total number of selections will be the number
+ of already generated selections, plus $k$ for every pair, plus one for the
+ statement itself: $\frac{k(k+1)}{2} + k +
+ 1 = \frac{k(k+1)+2k+2}{2} = \frac{k(k+1)+2(k+1)}{2} = \frac{(k+1)(k+2)}{2} =
+ \frac{(k+1)((k+1)+1)}{2} = \sum_{i=1}^{k+1} i$
+\end{proof}
+
+%\definition{A \emph{body of statements} is a sequence of statements where every
+%statement may have sub-statements.}
+
+\begin{theorem}
+ The number of text selections for a body of statements is maximized if all the
+ statements are at the same level.
+ \label{thm:textSelectionsMaximized}
+\end{theorem}
+
+\begin{proof}
+ Assume we have a body of, in total, $k$ statements. Then, the sum of the
+ lengths of all the lists of statements in the body, is also $k$. Let
+ $\{l,\ldots,m,(k-l-\ldots-m)\}$ be the lengths of the lists of statements in
+ the body, with $l+\ldots+m<k \Rightarrow \forall i \in \{l,\ldots,m\} : i < k$.
+
+ Then, the number of text selections that are generated for the $k$ statements
+ is
+
+ {
+ \small
+ \begin{align*}
+ \frac{l(l+1)}{2} + \ldots + \frac{m(m+1)}{2} +
+ \frac{(k-l-\ldots-m)((k-l-\ldots-m)+ 1)}{2} = \\
+ \frac{l^2+l}{2} + \ldots + \frac{m^2+m}{2} + \frac{k^2 - 2kl - \ldots - 2km +
+ l^2 + \ldots + m^2 + k - l - \ldots - m}{2} = \\
+ \frac{2l^2 - 2kl + \ldots + 2m^2 - 2km + k^2 + k}{2}
+ \end{align*}
+ }
+
+ \noindent It then remains to show that this inequality holds:
+
+ \begin{align*}
+ \frac{2l^2 - 2kl + \ldots + 2m^2 - 2km + k^2 + k}{2} < \frac{k(k+1)}{2} =
+ \frac{k^2 + k}{2}
+ \end{align*}
+
+ \noindent By multiplication by $2$ on both sides, and by removing the equal
+ parts, we get
+
+ \begin{align*}
+ 2l^2 - 2kl + \ldots + 2m^2 - 2km < 0
+ \end{align*}
+
+ Since $\forall i \in \{l,\ldots,m\} : i < k$, we have that $\forall i \in
+ \{l,\ldots,m\} : 2ki > 2i^2$, so all the pairs of parts on the form $2i^2-2ki$
+ are negative. In sum, the inequality holds.
+
+\end{proof}
+
+Therefore, the complexity for the number of selections that needs to be analyzed
+for a body of $n$ statements is $O\bigl(\frac{n(n+1)}{2}\bigr) = O(n^2)$.
+
+\section{Disqualifying a selection}
+Certain text selections would lead to broken code if used as input to the
+\ExtractAndMoveMethod refactoring. To avoid this, we have to check all text
+selections for such conditions before they are further analyzed. This section
+is therefore going to present some properties that make a selection unsuitable
+for our refactoring.
+
+\subsection{A call to a protected or package-private method}
+If a text selection contains a call to a protected or package-private method, it
+would not be safe to move it to another class. The reason for this, is that we
+cannot know if the called method is being overridden by some subclass of the
+\gloss{enclosingClass}, or not.
+
+Imagine that the protected method \method{foo} is declared in class \m{A},
+and overridden in class \m{B}. The method \method{foo} is called from within a
+selection done to a method in \m{A}. We want to extract and move this selection
+to another class. The method \method{foo} is not public, so the \MoveMethod
+refactoring must make it public, making the extracted method able to call it
+from the extracted method's new location. The problem is, that the now public
+method \method{foo} is overridden in a subclass, where it has a protected
+status. This makes the compiler complain that the subclass \m{B} is trying to
+reduce the visibility of a method declared in its superclass \m{A}. This is not
+allowed in Java, and for good reasons. It would make it possible to make a
+subclass that could not be a substitute for its superclass.
+
+The problem this check helps to avoid, is a little subtle. The problem does not
+arise in the class where the change is done, but in a class derived from it.
+This shows that classes acting as superclasses are especially fragile to
+introducing errors in the context of automated refactoring.
+\begin{comment}
+This is also shown in bug\ldots \todoin{File Eclipse bug report}
+\end{comment}
+
+\subsection{A double class instance creation}
+The following is a problem caused solely by the underlying \MoveMethod
+refactoring. The problem occurs if two classes are instantiated such that the
+first constructor invocation is an argument to a second, and that the first
+constructor invocation takes an argument that is built up using a field. As an
+example, say that \var{name} is a field of the enclosing class, and we have the
+expression \code{new A(new B(name))}. If this expression is located in a
+selection that is moved to another class, \var{name} will be left untouched,
+instead of being prefixed with a variable of the same type as it is declared in.
+If \var{name} is the destination for the move, it is not replaced by
+\code{this}, or removed if it is a prefix to a member access
+(\code{name.member}), but it is still left by itself.
+
+Situations like this would lead to code that will not compile. Therefore, we
+have to avoid them by not allowing selections to contain such double class
+instance creations that also contains references to fields.
+\begin{comment}
+\todoin{File Eclipse bug report}
+\end{comment}
+
+\subsection{Instantiation of non-static inner class}
+When a non-static inner class is instantiated, this must happen in the scope of
+its declaring class. This is because it must have access to the members of the
+declaring class. If the inner class is public, it is possible to instantiate it
+through an instance of its declaring class, but this is not handled by the
+underlying \MoveMethod refactoring.
+
+Performing a move on a method that instantiates a non-static inner class, will
+break the code if the instantiation is not handled properly. For this reason,
+selections that contains instantiations of non-static inner classes are deemed
+unsuitable for the \ExtractAndMoveMethod refactoring.
+
+\subsection{References to enclosing instances of the enclosing class}
+The title of this section may be a little hard to grasp at first. What it means
+is that there is a (non-static) class \m{C} that is declared in the scope of
+possibly multiple other classes. And there is a statement in the body of a
+method declared in class \m{C}, that contains a reference to one or more
+instances of these enclosing classes of \m{C}.
+
+The problem with this, is that these references may not be valid if they are
+moved to another class. Theoretically, some situations could easily be solved by
+passing, to the moved method, a reference to the instance where the problematic
+referenced member is declared. This should work in the case where this member is
+publicly accessible. This is not done in the underlying \MoveMethod refactoring,
+so it cannot be allowed in the \ExtractAndMoveMethod refactoring either.
+
+\subsection{Inconsistent return statements}
+To verify that a text selection is consistent with respect to return statements,
+we must check that if a selection contains a return statement, then every
+possible execution path within the selection ends in either a return or a throw
+statement. This property is important regarding the \ExtractMethod refactoring.
+If it holds, it means that a method could be extracted from the selection, and a
+call to it could be substituted for the selection. If the method has a non-void
+return type, then a call to it would also be a valid return point for the
+calling method. If its return value is of the void type, then the \ExtractMethod
+refactoring will append an empty return statement to the back of the method
+call. Therefore, the analysis does not discriminate on either kinds of return
+statements, with or without a return value.
+
+A throw statement is accepted anywhere a return statement is required. This is
+because a throw statement causes an immediate exit from the current block,
+together with all outer blocks in its control flow that does not catch the
+thrown exception.
+
+Return statements can be either explicit or implicit. An \emph{explicit} return
+statement is formed by using the \code{return} keyword, while an \emph{implicit}
+return statement is a statement that is not formed using \code{return}, but must
+be the last statement of a method that can have any side effects. This can
+happen in methods with a void return type. An example is a statement that is
+inside one or more blocks. The last statement of a method could for instance be
+a synchronized statement, but the last statement that is executed in the method,
+and that can have any side effects, may be located inside the body of the
+synchronized statement.
+
+We can start the check for this property by looking at the last statement of a
+selection to see if it is a return statement (explicit or implicit) or a throw
+statement. If this is the case, then the property holds, assuming the selected
+code does not contain any compilation errors. All execution paths within the
+selection should end in either this, or another, return or throw statement.
+\todoin{State somewhere that we assume no compilation errors?}
+
+If the last statement of the selection is not a return or throw, the execution
+of it must eventually end in one for the selection to be legal. This means that
+all branches of the last statement of every branch must end in a return or
+throw. Given this recursive definition, there are only five types of statements
+that are guaranteed to end in a return or throw if their child branches does.
+All other statements would have to be considered illegal. The first three:
+Block-statements, labeled statements and do-statements are all kinds of
+fall-through statements that always gets their body executed. Do-statements
+would not make much sense if written such that they
+always ends after the first round of execution of their body, but that is not
+our concern. The remaining two statements that can end in a return or throw are
+if-statements and try-statements.
+
+For an if-statement, the rule is that if its then-part does not contain any
+return or throw statements, this is considered illegal. If the then-part does
+contain a return or throw, the else-part is checked. If its else-part is
+non-existent, or it does not contain any return or throw statements, the
+statement is considered illegal. If an if-statement is not considered illegal,
+the bodies of its two parts must be checked.
+
+Try-statements are handled much the same way as if-statements. The body of a
+try-statement must contain a return or throw. The same applies to its catch
+clauses and finally body.
+
+\subsection{Ambiguous return values}
+The problem with ambiguous return values arise when a selection is chosen to be
+extracted into a new method, but it needs to return more than one value from
+that method.
+
+This problem occurs in two situations. The first situation arise when there is
+more than one local variable that is both assigned to within a selection and
+also referenced after the selection. The other situation occur when there is
+only one such assignment, but the selection also contain return statements.
+
+Therefore we must examine the selection for assignments to local variables that
+are referenced after the text selection. Then we must verify that not more than
+one such reference is done, or zero if any return statements are found.
+
+\subsection{Illegal statements}
+An illegal statement may be a statement that is of a type that is never allowed,
+or it may be a statement of a type that is only allowed if certain conditions
+are true.
+
+Any use of the \var{super} keyword is prohibited, since its meaning is altered
+when moving a method to another class.
+
+For a \emph{break} statement, there are two situations to consider: A break
+statement with or without a label. If the break statement has a label, it is
+checked that whole of the labeled statement is inside the selection. If the
+break statement does not have a label attached to it, it is checked that its
+innermost enclosing loop or switch statement also is inside the selection.
+
+The situation for a \emph{continue} statement is the same as for a break
+statement, except that it is not allowed inside switch statements.
+
+Regarding \emph{assignments}, two types of assignments are allowed: Assignments
+to non-final variables and assignments to array access. All other assignments
+are regarded illegal.
+
+\todoin{Expand with more illegal statements and/or conclude that I did not have
+time to analyze all statement types.}
+
+\section{Disqualifying selections from the
+example}\label{sec:disqualifyingExample}
+Among the selections we found for the code in \myref{lst:grandExample}, not many
+of them must be disqualified on the basis of containing something illegal. The
+only statement causing trouble is the break statement in line 18. None of the
+selections on nesting level 2 can contain this break statement, since the
+innermost switch statement is not inside any of these selections.
+
+This means that the text selections $(18)$, $(16,18)$ and $(17,18)$ can be
+excluded from further consideration, and we are left with the following
+selections.
+
+\begin{description}
+ \item[Level 1 (10 selections)] \hfill \\
+ $\{(5,9), (11), (12), (14,21), (5,11), (5,12), (5,21), (11,12),
+ (11,21), \\(12,21)\}$
+
+ \item[Level 2 (10 selections)] \hfill \\
+ $\{(6), (7), (8), (6,7), (6,8), (7,8), (16), (17), (16,17), (20)\}$
+\end{description}
+
+\section{Finding a move target}
+In the analysis needed to perform the \ExtractAndMoveMethod refactoring
+automatically, the selection we choose is found among all the selections that
+has a possible move target. Therefore, the best possible move target must be
+found for all the candidate selections, so that we are able to sort out the
+selection that is best suited for the refactoring.
+
+To find the best move target for a specific text selection, we first need to
+find all the possible targets. Since the target must be a local variable or a
+field, we are basically looking for names within the selection; names that
+represents references to variables.
+
+The names we are looking for, we call prefixes. This is because we are not
+interested in names that occur in the middle of a dot-separated sequence of
+names. We are only interested in names that constitutes prefixes of other names,
+possibly themselves. The reason for this, is that two lexically equal names need
+not be referencing the same variable, if they themselves are not referenced via
+the same prefix. Consider the two method calls \code{a.x.foo()} and
+\code{b.x.foo()}. Here, the two references to \code{x}, in the middle of the
+qualified names both preceding \code{foo()}, are not referencing the same
+variable. Even though the variables may share the type, and the method
+\method{foo} thus is the same for both, we would not know through which of the
+variables \var{a} or \var{b} we should call the extracted method.
+
+The possible move targets are then the prefixes that are not among a subset of
+the prefixes that are not valid move targets \see{s:unfixes}. Also, prefixes
+that are just simple names, and have only one occurrence, are left out. This is
+because they are not going to have any positive effect on coupling between
+classes, and are only going to increase the complexity of the code.
+
+For finding the best move target among these safe prefixes, a simple heuristic
+is used. It is as simple as choosing the prefix that is most frequently
+referenced within the selection.
+
+\section{Unfixes}\label{s:unfixes}
+The prefixes that are not valid as move targets are called unfixes.
+
+An unfix can be a name that is assigned to within a selection. The reason that
+this cannot be allowed, is that the result would be an assignment to the
+\type{this} keyword, which is not valid in Java \see{eclipse_bug_420726}.
+
+Prefixes that originates from variable declarations within the same selection
+are also considered unfixes. This is because when a method is moved, it needs to
+be called through a variable. If this variable is also declared within the
+method that is to be moved, this obviously cannot be done.
+
+Also considered as unfixes are variable references that are of types that are
+not suitable for moving methods to. This can either be because it is not
+physically possible to move a method to the desired class or that it will cause
+compilation errors by doing so.
+
+If the type binding for a name is not resolved it is considered and unfix. The
+same applies to types that is only found in compiled code, so they have no
+underlying source that is accessible to us. (E.g. the \type{java.lang.String}
+class.)
+
+Interfaces types are not suitable as targets. This is simply because interfaces
+in Java cannot contain methods with bodies. (This thesis does not deal with
+features of Java versions later than Java 7. Java 8 has interfaces with default
+implementations of methods.)
+
+Neither are local types allowed. This accounts for both local and anonymous
+classes. Anonymous classes are effectively the same as interface types with
+respect to unfixes. Local classes could in theory be used as targets, but this
+is not possible due to limitations of the way the \refa{Extract and Move Method}
+refactoring has to be implemented. The problem is that the refactoring is done
+in two steps, so the intermediate state between the two refactorings would not
+be legal Java code. In the intermediate step for the case where a local class is
+the move target, the extracted method would need to take the local class as a
+parameter. This new method would need to live in the scope of the declaring
+class of the originating method. The local class would then not be in the scope
+of the extracted method, thus bringing the source code into an illegal state.
+One could imagine that the method was extracted and moved in one operation,
+without an intermediate state. Then it would make sense to include variables
+with types of local classes in the set of legal targets, since the local classes
+would then be in the scopes of the method calls. If this makes any difference
+for software metrics that measure coupling would be a different discussion.
+
+
+\begin{listing}[htb]
+\begin{multicols}{2}
+\begin{minted}[frame=topline,label=Before,framesep=\mintedframesep]{java}
+void declaresLocalClass() {
+ class LocalClass {
+ void foo() {}
+ void bar() {}
+ }
+
+ LocalClass inst =
+ new LocalClass();
+ inst.foo();
+ inst.bar();
+}
+\end{minted}
+
+\columnbreak
+
+\begin{minted}[frame=topline,label={After Extract
+ Method},framesep=\mintedframesep]{java}
+void declaresLocalClass() {
+ class LocalClass {
+ void foo() {}
+ void bar() {}
+ }
+
+ LocalClass inst =
+ new LocalClass();
+ fooBar(inst);
+}
+
+// Intermediate step
+void fooBar(LocalClass inst) {
+ inst.foo();
+ inst.bar();
+}
+\end{minted}
+\end{multicols}
+\caption{When the \refa{Extract and Move Method} tries to use a variable with a
+local type as the move target, an intermediate step is performed that is not
+allowed. Here: \type{LocalClass} is not in the scope of \method{fooBar} in its
+intermediate location.}
+\label{lst:extractMethod_LocalClass}
+\end{listing}
+
+The last class of names that are considered unfixes are names used in null
+tests. These are tests that reads like this: if \code{<name>} equals \var{null}
+then do something. If allowing variables used in those kinds of expressions as
+targets for moving methods, we would end up with code containing boolean
+expressions like \code{this == null}, which would not be meaningful, since
+\var{this} would never be \var{null}.
+
+\section{Finding the example selections that have possible targets}
+We now pick up the thread from \myref{sec:disqualifyingExample} where we have a
+set of text selections that needs to be analyzed to find out if some of them are
+suitable targets for the \ExtractAndMoveMethod refactoring.
+
+We start by analyzing the text selections for nesting level 2, because these
+results can be used to reason about the selections for nesting level 1. First we
+have all the single-statement selections.
+
+\begin{description}
+ \item[Selections $(6)$, $(8)$ and $(20)$.] \hfill \\
+ All these selections have a prefix that contains a possible target, namely
+ the variable \var{a}. The problem is that the prefixes are only one segment
+ long, and their frequency counts are only 1 as well. None of these
+ selections are therefore considered as suitable candidates for the
+ refactoring.
+
+ \item[Selection $(7)$.] \hfill \\
+ This selection contains the unfix \var{a}, and no other possible targets.
+ The reason for \var{a} being an unfix is that it is assigned to within the
+ selection. Selection $(7)$ is therefore unsuited as a refactoring candidate.
+
+ \item[Selections $(16)$ and $(17)$.] \hfill \\
+ These selections both have a possible target. The target for both selections
+ is the variable \var{b}. Both the prefixes have frequency 1. We denote this
+ with the new tuples $((16), \texttt{b.a}, f(1))$ and $((17), \texttt{b.a},
+ f(1))$. They contain the selection, the prefix with the target and the
+ frequency for this prefix.
+
+\end{description}
+
+Then we have all the text selections from level 2 that are composed of multiple
+statements:
+
+\begin{description}
+ \item[Selections $(6,7)$, $(6,8)$ and $(7,8)$.] \hfill \\
+ All these selections are disqualified for the reason that they contain the
+ unfix \var{a}, due to the assignment, and no other possible move targets.
+
+ \item[Selection $(16,17)$.] \hfill \\
+ This selection is the last selection that is not analyzed on nesting level
+ 2. It contains only one possible move target, and that is the variable
+ \var{b}. It also contains only one prefix \var{b.a}, with frequency count
+ 2. Therefore we have a new candidate $((16,17), \texttt{b.a}, f(2))$.
+
+\end{description}
+
+Moving on to the text selections for nesting level 1, starting with the
+single-statement selections:
+
+\begin{description}
+ \item[Selection $(5,9)$.] \hfill \\
+ This selection contains two variable references that must be analyzed to see
+ if they are possible move candidates. The first one is the variable
+ \var{bool}. This variable is of type \type{boolean}, that is a primary type
+ and therefore not possible to make any changes to. The second variable is
+ \var{a}. The variable \var{a} is an unfix in $(5,9)$, for the same reason as
+ in the selections $(6,7)$, $(7,8)$ and $(6,8)$. So selection $(5,9)$
+ contains no possible move targets.
+
+ \item[Selections $(11)$ and $(12)$.] \hfill \\
+ These selections are disqualified for the same reasons as selections $(6)$
+ and $(8)$. Their prefixes are one segment long and are referenced only one
+ time.
+
+ \item[Selection $(14,21)$] \hfill \\
+ This is the switch statement from \myref{lst:grandExample}. It contains the
+ relevant variable references \var{val}, \var{a} and \var{b}. The variable
+ \var{val} is a primary type, just as \var{bool}. The variable \var{a} is
+ only found in one statement, and in a prefix with only one segment, so it is
+ not considered to be a possible move target. The only variable left is
+ \var{b}. Just as in the selection $(16,17)$, \var{b} is part of the prefix
+ \code{b.a}, that has 2 appearances. We have found a new candidate $((14,21),
+ \texttt{b.a}, f(2))$.
+
+\end{description}
+
+It remains to see if we get any new candidates by analyzing the multi-statement
+text selections for nesting level 1:
+
+\begin{description}
+ \item[Selections $(5,11)$ and $(5,12)$.] \hfill \\
+ These selections are disqualified for the same reason as $(5,9)$. The only
+ possible move target \var{a} is an unfix.
+
+ \item[Selection $(5,21)$.] \hfill \\
+ This is whole of the method body in \myref{lst:grandExample}. The variables
+ \var{a}, \var{bool} and \var{val} are either an unfix or primary types. The
+ variable \var{b} is the only possible move target, and we have, again, the
+ prefix \code{b.a} as the center of attention. The refactoring candidate is
+ $((5,21), \texttt{b.a}, f(2))$.
+
+ \item[Selection $(11,12)$.] \hfill \\
+ This small selection contains the prefix \code{a} with frequency 2, and no
+ unfixes. The candidate is $((11,12), \texttt{a}, f(2))$.
+
+ \item[Selection $(11,21)$] \hfill \\
+ This selection contains the selection $(11,12)$ in addition to the switch
+ statement. The selection has two possible move targets. The first one is
+ \var{b}, in a prefix with frequency 2. The second is \var{a}, although it
+ is in a simple prefix, it is referenced 3 times, and is therefore chosen
+ as the target for the selection. The new candidate is $((11,21),
+ \texttt{a}, f(3))$.
+
+ \item[Selection $(12,21)$.] \hfill \\
+ This selection is similar to the previous $(11,21)$, only that \var{a} now
+ has frequency count 2. This means that the prefixes \code{a} and
+ \code{b.a} both have the count 2. Of the two, \code{b.a} is preferred,
+ since it has more segments than \code{a}. Thus the candidate for this
+ selection is $((12,21), \texttt{b.a}, f(2))$.
+
+\end{description}
+
+For the method in \myref{lst:grandExample} we therefore have the following 8
+candidates for the \ExtractAndMoveMethod refactoring: $\{((16), \texttt{b.a},
+f(1)), ((17), \texttt{b.a}, f(1)), ((16,17), \texttt{b.a}, f(2)), ((14,21),
+\texttt{b.a}, f(2)), \\ ((5,21), \texttt{b.a}, f(2)), ((11,12), \texttt{a},
+f(2)), ((11,21), \texttt{a}, f(3)), ((12,21), \texttt{b.a}, f(2))\}$.
+
+It now only remains to specify an order for these candidates, so we can choose
+the most suitable one to refactor.
+
+
+\section{Choosing the selection}\label{sec:choosingSelection}
+When choosing a selection between the text selections that have possible move
+targets, the selections need to be ordered. The criteria below are presented in
+the order they are prioritized. If not one selection is favored over the other
+for a concrete criterion, the selections are evaluated by the next criterion.
+
+\begin{enumerate}
+ \item The first criterion that is evaluated is whether a selection contains
+ any unfixes or not. If selection \m{A} contains no unfixes, while selection
+ \m{B} does, selection \m{A} is favored over selection \m{B}. This is
+ because, if we can, we want to avoid moving such as assignments and variable
+ declarations. This is done under the assumption that, if possible, avoiding
+ selections containing unfixes will make the code moved a little cleaner.
+
+ \item The second criterion that is evaluated is whether a selection contains
+ multiple possible targets or not. If selection \m{A} has only one possible
+ target, and selection \m{B} has multiple, selection \m{A} is favored. If
+ both selections have multiple possible targets, they are considered equal
+ with respect to this criterion. The rationale for this heuristic is that we
+ would prefer not to introduce new couplings between classes when performing
+ the \ExtractAndMoveMethod refactoring.
+
+ \item When evaluating this criterion, this is with the knowledge that
+ selection \m{A} and \m{B} both have one possible target, or multiple
+ possible targets. Then, if the move target candidate of selection \m{A} has
+ a higher reference count than the target candidate of selection \m{B},
+ selection \m{A} is favored. The reason for this is that we would like to
+ move the selection that gets rid of the most references to another class.
+
+ \item The last criterion is that if the frequencies of the targets chosen for
+ both selections are equal, the selection with the target that is part of the
+ prefix with highest number of segments is favored. This is done to favor
+ indirection.
+
+\end{enumerate}
+
+If none of the above mentioned criteria favors one selection over another, the
+selections are considered to be equally good candidates for the
+\ExtractAndMoveMethod refactoring.
+
+\section{Concluding the example}
+For choosing one of the remaining selections, we need to order our candidates
+after the criteria in the previous section. Below we have the candidates ordered
+in descending order, with the ``best'' candidate first:
+
+\begin{multicols}{2}
+\begin{enumerate}
+ \item $((16,17), \texttt{b.a}, f(2))$
+ \item $((11,12), \texttt{a}, f(2))$
+ \item $((16), \texttt{b.a}, f(1))$
+ \item $((17), \texttt{b.a}, f(1))$
+
+ % With unfixes:
+ % Many possible targets
+ \item $((11,21), \texttt{a}, f(3))$
+ \item $((5,21), \texttt{b.a}, f(2))$
+ \item $((12,21), \texttt{b.a}, f(2))$
+ \item $((14,21), \texttt{b.a}, f(2))$
+
+\end{enumerate}
+\end{multicols}
+
+\begin{comment}
+5 if (bool) {
+6 a.foo();
+7 a = new A();
+8 a.bar();
+9 }
+10
+11 a.foo();
+12 a.bar();
+13
+14 switch (val) {
+15 case 1:
+16 b.a.foo();
+17 b.a.bar();
+18 break;
+19 default:
+20 a.foo();
+21 }
+\end{comment}
+
+The candidates ordered 5-8 all have unfixes in them, therefore they are ordered
+last. None of the candidates ordered 1-4 have multiple possible targets. The
+only interesting discussion is now why $(16,17)$ was favored over $(11,12)$.
+This is because the prefix \code{b.a} enclosing the move target of selection
+$(16,17)$ has one more segment than the prefix \code{a} of $(11,12)$.
+
+The selection is now extracted into a new method \method{gen\_123} and then
+moved to class \type{B}, since that is the type of the variable \var{b} that is
+the target from the chosen refactoring candidate. The name of the method has a
+randomly generated suffix. In the refactoring implementation, the extracted
+methods follow the pattern \code{generated\_<long>}, where \code{<long>} is a
+pseudo-random long value. This is shortened here to make the example readable.
+The result after the refactoring is shown in \myref{lst:grandExampleResult}.
+
+\begin{listing}[htb]
+ \begin{multicols}{2}
+ \begin{minted}[linenos]{java}
+class C {
+ A a; B b; boolean bool;
+
+ void method(int val) {
+ if (bool) {
+ a.foo();
+ a = new A();
+ a.bar();
+ }
+
+ a.foo();
+ a.bar();
+
+ switch (val) {
+ case 1:
+ b.gen_123(this);
+ break;
+ default:
+ a.foo();
+ }
+ }
+}
+\end{minted}
+
+\columnbreak
+
+ \begin{minted}[]{java}
+public class B {
+ A a;
+ public void gen_123(C c) {
+ a.foo();
+ a.bar();
+ }
+}
+\end{minted}
+
+ \end{multicols}
+ \caption{The result after refactoring the class \type{C} of
+ \myref{lst:grandExample} with the \ExtractAndMoveMethod refactoring with
+ $((16,17), \texttt{b.a}, f(2))$ as input.}
+\label{lst:grandExampleResult}
+\end{listing}
-\chapter{Refactorings in Eclipse JDT: Design, Shortcomings and Wishful
-Thinking}\label{ch:jdt_refactorings}
+\chapter{Refactorings in Eclipse JDT: Design and
+Shortcomings}\label{ch:jdt_refactorings}
This chapter will deal with some of the design behind refactoring support in
-Eclipse, and the JDT in specific. After which it will follow a section about
-shortcomings of the refactoring API in terms of composition of refactorings. The
-chapter will be concluded with a section telling some of the ways the
-implementation of refactorings in the JDT could have worked to facilitate
-composition of refactorings.
+\name{Eclipse}, and the JDT in specific. After which it will follow a section
+about shortcomings of the refactoring API in terms of composition of
+refactorings.
\section{Design}
-The refactoring world of Eclipse can in general be separated into two parts: The
+The refactoring world of \name{Eclipse} can in general be separated into two parts: The
language independent part and the part written for a specific programming
language -- the language that is the target of the supported refactorings.
\todo{What about the language specific part?}
\url{https://www.eclipse.org/articles/Article-LTK/ltk.html} and
\url{http://www.eclipse.org/articles/article.php?file=Article-Unleashing-the-Power-of-Refactoring/index.html},
the LTK source code and my own memory.}, or LTK for short, is the framework that
-is used to implement refactorings in Eclipse. It is language independent and
+is used to implement refactorings in \name{Eclipse}. It is language independent and
provides the abstractions of a refactoring and the change it generates, in the
form of the classes \typewithref{org.eclipse.ltk.core.refactoring}{Refactoring}
and \typewithref{org.eclipse.ltk.core.refactoring}{Change}.
\subsection{Absence of Generics in Eclipse Source Code}
This section is not only concerning the JDT refactoring API, but also large
-quantities of the Eclipse source code. The code shows a striking absence of the
+quantities of the \name{Eclipse} source code. The code shows a striking absence of the
Java language feature of generics. It is hard to read a class' interface when
methods return objects or takes parameters of raw types such as \type{List} or
\type{Map}. This sometimes results in having to read a lot of source code to
the refactoring in a single step. This is not the way it appears when a sequence
of JDT refactorings is executed. It leaves the undo history filled up with
individual undo actions corresponding to every single JDT refactoring in the
-sequence. This problem is not trivial to handle in Eclipse.
-\See{hacking_undo_history}
+sequence. This problem is not trivial to handle in \name{Eclipse}
+\see{hacking_undo_history}.
+
-\section{Wishful Thinking}
-\todoin{???}
\chapter{Composite Refactorings in Eclipse}
\section{A Simple Ad Hoc Model}
-As pointed out in \myref{ch:jdt_refactorings}, the Eclipse JDT refactoring model
+As pointed out in \myref{ch:jdt_refactorings}, the \name{Eclipse} JDT refactoring model
is not very well suited for making composite refactorings. Therefore a simple
model using changer objects (of type \type{RefaktorChanger}) is used as an
-abstraction layer on top of the existing Eclipse refactorings, instead of
+abstraction layer on top of the existing \name{Eclipse} refactorings, instead of
extending the \typewithref{org.eclipse.ltk.core.refactoring}{Refactoring} class.
The use of an additional abstraction layer is a deliberate choice. It is due to
This is a composite refactoring, and hence is built up using several primitive
refactorings. These basic building blocks are, as its name implies, the
\ExtractMethod refactoring\citing{refactoring} and the \MoveMethod
-refactoring\citing{refactoring}. In Eclipse, the implementations of these
+refactoring\citing{refactoring}. In \name{Eclipse}, the implementations of these
refactorings are found in the classes
\typewithref{org.eclipse.jdt.internal.corext.refactoring.code}{ExtractMethodRefactoring}
and
its visibility and some not so interesting parameters.
\subsubsection{The MoveInstanceMethodProcessor Class}
-For the Move Method, the processor requires a little more advanced input than
-the class for the Extract Method. For construction it requires a method
+For the \refa{Move Method}, the processor requires a little more advanced input than
+the class for the \refa{Extract Method}. For construction it requires a method
handle\typeref{org.eclipse.jdt.core.IMethod} for the method that is to be moved.
Then the target for the move have to be supplied as the variable binding from a
chosen variable declaration. In addition to this, one have to set some
class is a subclass of the class
\typewithref{no.uio.ifi.refaktor.changers}{RefaktorChanger}. It is responsible
for analyzing and finding the best target for, and also executing, a composition
-of the Extract Method and Move Method refactorings. This particular changer is
+of the \refa{Extract Method} and \refa{Move Method} refactorings. This particular changer is
the one of my changers that is closest to being a true LTK refactoring. It can
be reworked to be one if the problems with overlapping changes are resolved. The
changer requires a text selection and the name of the new method, or else a
basic offset, length and similar methods, also carry an instance of the
underlying compilation unit handle for the selection.
-\subsubsection{The \type{ExtractAndMoveMethodAnalyzer}}
+\subsubsection{The
+ \type{ExtractAndMoveMethodAnalyzer}}\label{extractAndMoveMethodAnalyzer}
The analysis and precondition checking is done by the
\typewithref{no.uio.ifi.refaktor.analyze.analyzers}{ExtractAnd\-MoveMethodAnalyzer}.
First is check whether the selection is a valid selection or not, with respect
For finding the best suitable target the analyzer is using a
\typewithref{no.uio.ifi.refaktor.analyze.collectors}{PrefixesCollector} that
-collects all the possible candidates for the refactoring. All the non-candidates
-is found by an
+collects all the possible candidate targets for the refactoring. All the
+non-candidates is found by an
\typewithref{no.uio.ifi.refaktor.analyze.collectors}{UnfixesCollector} that
collects all the targets that will give some kind of error if used. (For
-details about the property collectors, se \myref{propertyCollectors}.) All
+details about the property collectors, see \myref{propertyCollectors}.) All
prefixes (and unfixes) are represented by a
\typewithref{no.uio.ifi.refaktor.extractors}{Prefix}, and they are collected
into sets of prefixes. The safe prefixes is found by subtracting from the set of
candidate prefixes the prefixes that is enclosing any of the unfixes. A prefix
is enclosing an unfix if the unfix is in the set of its sub-prefixes. As an
-example, \texttt{``a.b''} is enclosing \texttt{``a''}, as is \texttt{``a''}. The
-safe prefixes is unified in a \type{PrefixSet}. If a prefix has only one
-occurrence, and is a simple expression, it is considered unsuitable as a move
-target. This occurs in statements such as \texttt{``a.foo()''}. For such
-statements it bares no meaning to extract and move them. It only generates an
-extra method and the calling of it.
+example, \code{``a.b''} is enclosing \code{``a''}, as is \code{``a''}. The safe
+prefixes is unified in a \type{PrefixSet}. If a prefix has only one occurrence,
+and is a simple expression, it is considered unsuitable as a move target. This
+occurs in statements such as \code{``a.foo()''}. For such statements it bares no
+meaning to extract and move them. It only generates an extra method and the
+calling of it.
The most suitable target for the refactoring is found by finding the prefix with
the most occurrences. If two prefixes have the same occurrence count, but they
-differ in length, the longest of them is chosen.
-
-\todoin{Clean up sections/subsections.}
+differ in the number of segments, the one with most segments is chosen.
-\subsubsection{The \type{ExtractAndMoveMethodExecutor}}
+\subsubsection{The
+ \type{ExtractAndMoveMethodExecutor}}\label{extractAndMoveMethodExecutor}
If the analysis finds a possible target for the composite refactoring, it is
executed by an
\typewithref{no.uio.ifi.refaktor.change.executors}{ExtractAndMoveMethodExecutor}.
\typewithref{no.uio.ifi.refaktor.change.executors}{MoveMethodRefactoringExecutor}.
The \type{ExtractAndMoveMethodExecutor} is responsible for gluing the two
together by feeding the \type{MoveMethod\-RefactoringExecutor} with the
-resources needed after executing the extract method refactoring.
-\See{postExtractExecution}
+resources needed after executing the extract method refactoring.
\subsubsection{The \type{ExtractMethodRefactoringExecutor}}
This executor is responsible for creating and executing an instance of the
\subsubsection{The \type{MoveMethodRefactoringExecutor}}
This executor is responsible for creating and executing an instance of the
\type{MoveRefactoring}. The move refactoring is a processor-based refactoring,
-and for the Move Method refactoring it is the \type{MoveInstanceMethodProcessor}
+and for the \refa{Move Method} refactoring it is the \type{MoveInstanceMethodProcessor}
that is used.
The handle for the method to be moved is found on the basis of the information
-gathered after the execution of the Extract Method refactoring. The only
+gathered after the execution of the \refa{Extract Method} refactoring. The only
information the \type{ExtractMethodRefactoring} is sharing after its execution,
regarding find the method handle, is the textual representation of the new
method signature. Therefore it must be parsed, the strings for types of the
selection, since an extracted method must end up in the same type as the
originating method.
-When analyzing a selection prior to performing the Extract Method refactoring, a
+When analyzing a selection prior to performing the \refa{Extract Method} refactoring, a
target is chosen. It has to be a variable binding, so it is either a field or a
local variable/parameter. If the target is a field, it can be used with the
\type{MoveInstanceMethodProcessor} as it is, since the extracted method still is
\subsection{The
SearchBasedExtractAndMoveMethodChanger}\label{searchBasedExtractAndMoveMethodChanger}
-\todoin{Write\ldots}
+The
+\typewithref{no.uio.ifi.refaktor.change.changers}{SearchBasedExtractAndMoveMethodChanger}
+is a changer whose purpose is to automatically analyze a method, and execute the
+\ExtractAndMoveMethod refactoring on it if it is a suitable candidate for the
+refactoring.
+
+First, the \typewithref{no.uio.ifi.refaktor.analyze.analyzers}{SearchBasedExtractAndMoveMethodAnalyzer} is used
+to analyze the method. If the method is found to be a candidate, the result from
+the analysis is fed to the \type{ExtractAndMoveMethodExecutor}, whose job is to
+execute the refactoring \see{extractAndMoveMethodExecutor}.
+
+\subsubsection{The SearchBasedExtractAndMoveMethodAnalyzer}
+This analyzer is responsible for analyzing all the possible text selections of a
+method and then choose the best result out of the analysis results that is, by
+the analyzer, considered to be the potential candidates for the Extract and Move
+Method refactoring.
+
+Before the analyzer is able to work with the text selections of a method, it
+needs to generate them. To do this, it parses the method to obtain a
+\type{MethodDeclaration} for it \see{astEclipse}. Then there is a statement
+lists creator that creates statements lists of the different groups of
+statements in the body of the method declaration. A text selections generator
+generates text selections of all the statement lists for the analyzer to work
+with.
+
+\paragraph{The statement lists creator}
+is responsible for generating lists of statements for all the possible nesting
+levels of statements in the method. The statement lists creator is implemented
+as an AST visitor \see{astVisitor}. It generates lists of statements by visiting
+all the blocks in the method declaration and stores their statements in a
+collection of statement lists. In addition, it visits all of the other
+statements that can have a statement as a child, such as the different control
+structures and the labeled statement.
+
+The switch statement is the only kind of statement that is not straight forward
+to obtain the child statements from. It stores all of its children in a flat
+list. Its switch case statements are included in this list. This means that
+there are potential statement lists between all of these case statements. The
+list of statements from a switch statement is therefore traversed, and the
+statements between the case statements are grouped as separate lists.
+
+The highlighted part of \myref{lst:grandExample} shows an example of how the
+statement lists creator would separate a method body into lists of statements.
+
+\paragraph{The text selections generator} generates text selections for each
+list of statements from the statement lists creator. The generator generates a
+text selection for every sub-sequence of statements in a list. For a sequence of
+statements, the first statement and the last statement span out a text
+selection.
+
+In practice, the text selections are calculated by only one traversal of the
+statement list. There is a set of generated text selections. For each statement,
+there is created a temporary set of selections, in addition to a text selection
+based on the offset and length of the statement. This text selection is added to
+the temporary set. Then the new selection is added with every selection from the
+set of generated text selections. These new selections are added to the
+temporary set. Then the temporary set of selections is added to the set of
+generated text selections. The result of adding two text selections is a new
+text selection spanned out by the two addends.
+
+\begin{comment}
+\begin{listing}[h]
+\def\charwidth{5.7pt}
+\def\indent{4*\charwidth}
+\def\lineheight{\baselineskip}
+\def\mintedtop{\lineheight}
+
+\begin{tikzpicture}[overlay, yscale=-1]
+ \tikzstyle{overlaybox}=[fill=lightgray,opacity=0.2]
+
+ \draw[overlaybox] (2*\charwidth,\mintedtop) rectangle
+ +(18*\charwidth,\lineheight);
-\subsection{Finding the IMethod}\label{postExtractExecution}
-\todoin{Rename section. Write??}
+ \draw[overlaybox] (2*\charwidth,\mintedtop+\lineheight) rectangle
+ +(18*\charwidth,\lineheight);
+
+ \draw[overlaybox] (2*\charwidth,\mintedtop+3*\lineheight) rectangle
+ +(18*\charwidth,\lineheight);
+
+ \draw[overlaybox] (\indent-3*\charwidth,\mintedtop) rectangle
+ +(20*\charwidth,2*\lineheight);
+
+ \draw[overlaybox] (3*\charwidth,\mintedtop+\lineheight) rectangle
+ +(16*\charwidth,3*\lineheight);
+
+ \draw[overlaybox] (\indent,\mintedtop) rectangle
+ +(14*\charwidth,4*\lineheight);
+\end{tikzpicture}
+\begin{minted}{java}
+ statement one;
+ statement two;
+ ...
+ statement k;
+\end{minted}
+\caption{Example of how the text selections generator would generate text
+ selections based on a lists of statements. Each highlighted rectangle
+represents a text selection.}
+\label{lst:textSelectionsExample}
+\end{listing}
+\todoin{fix \myref{lst:textSelectionsExample}? Text only? All
+sub-sequences\ldots}
+\end{comment}
+
+\paragraph{Finding the candidate} for the refactoring is done by analyzing all
+the generated text selection with the \type{ExtractAndMoveMethodAnalyzer}
+\see{extractAndMoveMethodAnalyzer}. If the analyzer generates a useful result,
+an \type{ExtractAndMoveMethodCandidate} is created from it, that is kept in a
+list of potential candidates. If no candidates are found, the
+\type{NoTargetFoundException} is thrown.
+
+Since only one of the candidates can be chosen, the analyzer must sort out which
+candidate to choose. The sorting is done by the static \method{sort} method of
+\type{Collections}. The comparison in this sorting is done by an
+\type{ExtractAndMoveMethodCandidateComparator}.
+\todoin{Write about the
+ExtractAndMoveMethodCandidateComparator/FavorNoUnfixesCandidateComparator}
\subsection{The Prefix Class}
My first impulse was to remove the, in this case, last two undo changes from the
undo manager\typeref{org.eclipse.ltk.core.refactoring.IUndoManager} for the
-Eclipse refactorings, and then add them to a composite
+\name{Eclipse} refactorings, and then add them to a composite
change\typeref{org.eclipse.ltk.core.refactoring.CompositeChange} that could be
added back to the manager. The interface of the undo manager does not offer a
way to remove/pop the last added undo change, so a possible solution could be to
There is a technical challenge with this approach, and it relates to the undo
manager, and the concrete implementation
-UndoManager2\typeref{org.eclipse.ltk.internal.core.refactoring.UndoManager2}.
-This implementation is designed in a way that it is not possible to just add an
-undo change, you have to do it in the context of an active
+\typewithref{org.eclipse.ltk.internal.core.refactoring}{UndoManager2}. This
+implementation is designed in a way that it is not possible to just add an undo
+change, you have to do it in the context of an active
operation\typeref{org.eclipse.core.commands.operations.TriggeredOperations}.
One could imagine that it might be possible to trick the undo manager into
believing that you are doing a real change, by executing a refactoring that is
returning a kind of null change that is returning our composite change of undo
-refactorings when it is performed.
+refactorings when it is performed. But this is not the way to go.
Apart from the technical problems with this solution, there is a functional
problem: If it all had worked out as planned, this would leave the undo history
\chapter{Analyzing Source Code in Eclipse}
\section{The Java model}\label{javaModel}
-The Java model of Eclipse is its internal representation of a Java project. It
+The Java model of \name{Eclipse} is its internal representation of a Java project. It
is light-weight, and has only limited possibilities for manipulating source
-code. It is typically used as a basis for the Package Explorer in Eclipse.
+code. It is typically used as a basis for the Package Explorer in \name{Eclipse}.
The elements of the Java model is only handles to the underlying elements. This
means that the underlying element of a handle does not need to actually exist.
Hence the user of a handle must always check that it exist by calling the
\method{exists} method of the handle.
-The handles with descriptions is listed in \myref{tab:javaModel}.
+The handles with descriptions is listed in \myref{tab:javaModel}, while the
+hierarchy of the Java Model is shown in \myref{fig:javaModel}.
-\begin{table}[h]
+\begin{table}[htb]
+ \caption{The elements of the Java Model\citing{vogelEclipseJDT2012}.}
+ \label{tab:javaModel}
\centering
-
- \newcolumntype{L}[1]{>{\hsize=#1\hsize\raggedright\arraybackslash}X}%
% sum must equal number of columns (3)
- \begin{tabularx}{\textwidth}{| L{0.7} | L{1.1} | L{1.2} |}
- \hline
+ \begin{tabularx}{\textwidth}{@{} L{0.7} L{1.1} L{1.2} @{}}
+ \toprule
\textbf{Project Element} & \textbf{Java Model element} &
\textbf{Description} \\
- \hline
+ \midrule
Java project & \type{IJavaProject} & The Java project which contains all other objects. \\
- \hline
+ \midrule
Source folder /\linebreak[2] binary folder /\linebreak[3] external library &
\type{IPackageFragmentRoot} & Hold source or binary files, can be a folder
or a library (zip / jar file). \\
- \hline
+ \midrule
Each package & \type{IPackageFragment} & Each package is below the
\type{IPackageFragmentRoot}, sub-packages are not leaves of the package,
they are listed directed under \type{IPackageFragmentRoot}. \\
- \hline
+ \midrule
Java Source file & \type{ICompilationUnit} & The Source file is always below
the package node. \\
- \hline
- Types /\linebreak[2] Fields /\linebreak[3] Methods & \type{IType} /
- \linebreak[0]
- \type{IField} /\linebreak[3] \type{IMethod} & Types, fields and methods. \\
- \hline
+ \midrule
+ Types / Fields /\linebreak[3] Methods & \type{IType} / \type{IField}
+ /\linebreak[3] \type{IMethod} & Types, fields and methods. \\
+ \bottomrule
\end{tabularx}
- \caption{The elements of the Java Model. {\footnotesize Taken from
- \url{http://www.vogella.com/tutorials/EclipseJDT/article.html}}}
- \label{tab:javaModel}
\end{table}
-The hierarchy of the Java Model is shown in \myref{fig:javaModel}.
\begin{figure}[h]
\centering
child { node {\type{\{ IPackageFragmentRoot \}*}}}
;
\end{tikzpicture}
- \caption{The Java model of Eclipse. ``\type{\{ SomeElement \}*}'' means
- \type{SomeElement} zero or more times. For recursive structures,
+ \caption{The Java model of \name{Eclipse}. ``\type{\{ SomeElement \}*}'' means
+ ``\type{SomeElement} zero or more times``. For recursive structures,
``\type{\ldots}'' is used.}
\label{fig:javaModel}
\end{figure}
-\section{The Abstract Synax Tree}
-Eclipse is following the common paradigm of using an abstract syntaxt tree for
+\section{The Abstract Syntax Tree}
+\name{Eclipse} is following the common paradigm of using an abstract syntax tree for
source code analysis and manipulation.
When parsing program source code into something that can be used as a foundation
for analysis, the start of the process follows the same steps as in a compiler.
-This is all natural, because the way a compiler anayzes code is no different
+This is all natural, because the way a compiler analyzes code is no different
from how source manipulation programs would do it, except for some properties of
code that is analyzed in the parser, and that they may be differing in what
kinds of properties they analyze. Thus the process of translation source code
read the source code and divide it into tokens for the parser. Therefore, it is
also sometimes called a tokenizer. A token is a logical unit, defined in the
language specification, consisting of one or more consecutive characters. In
-the java language the tokens can for instance be the \var{this} keyword, a curly
+the Java language the tokens can for instance be the \var{this} keyword, a curly
bracket \var{\{} or a \var{nameToken}. It is recognized by the scanner on the
-basis of something eqivalent of a regular expression. This part of the process
+basis of something equivalent of a regular expression. This part of the process
is often implemented with the use of a finite automata. In fact, it is common to
specify the tokens in regular expressions, that in turn is translated into a
finite automata lexer. This process can be automated.
-The program component used to translate a a stream of tokens into something
+The program component used to translate a stream of tokens into something
meaningful, is called a parser. A parser is fed tokens from the scanner and
performs an analysis of the structure of a program. It verifies that the syntax
is correct according to the grammar rules of a language, that is usually
specified in a context-free grammar, and often in a variant of the
-\emph{Backus--Naur
+\name{Backus--Naur
Form}\footnote{\url{https://en.wikipedia.org/wiki/Backus-Naur\_Form}}. The
result coming from the parser is in the form of an \emph{Abstract Syntax Tree},
AST for short. It is called \emph{abstract}, because the structure does not
semantic analysis of the code.
As an example we can think of the expression \code{(5 + 7) * 2}. The root of
-this tree would in Eclipse be an \type{InfixExpression} with the operator
+this tree would in \name{Eclipse} be an \type{InfixExpression} with the operator
\var{TIMES}, and a left operand that is also an \type{InfixExpression} with the
operator \var{PLUS}. The left operand \type{InfixExpression}, has in turn a left
operand of type \type{NumberLiteral} with the value \var{``5''} and a right
right operand of type \type{NumberLiteral} and value \var{``2''}. The AST for
this expression is illustrated in \myref{fig:astInfixExpression}.
-Contrary to the Java Model, an abstract syntaxt tree is a heavy-weight
-representation of source code. It contains information about propertes like type
-bindings for variables and variable bindings for names.
+Contrary to the Java Model, an abstract syntax tree is a heavy-weight
+representation of source code. It contains information about properties like
+type bindings for variables and variable bindings for names.
\begin{figure}[h]
\label{fig:astInfixExpression}
\end{figure}
-\subsection{The AST in Eclipse}
-In Eclipse, every node in the AST is a child of the abstract superclass
+\subsection{The AST in Eclipse}\label{astEclipse}
+In \name{Eclipse}, every node in the AST is a child of the abstract superclass
\typewithref{org.eclipse.jdt.core.dom}{ASTNode}. Every \type{ASTNode}, among a
lot of other things, provides information about its position and length in the
source code, as well as a reference to its parent and to the root of the tree.
as an operand in compound expressions, as well as for names in type declarations
and such.
-There is an overview of some of the structure of an Eclipse AST in
+There is an overview of some of the structure of an \name{Eclipse} AST in
\myref{fig:astEclipse}.
\begin{figure}[h]
\draw (root.south) -- (body);
\end{tikzpicture}
- \caption{The format of the abstract syntax tree in Eclipse.}
+ \caption{The format of the abstract syntax tree in \name{Eclipse}.}
\label{fig:astEclipse}
\end{figure}
\todoin{Add more to the AST format tree? \myref{fig:astEclipse}}
\section{The ASTVisitor}\label{astVisitor}
-So far, the only thing that has been adressed is how the the data that is going
-to be the basis for our analysis is structured. Another aspect of it is how we
-are going to traverse the AST to gather the information we need, so we can
-conclude about the properties we are analysing. It is of course possible to
-start at the top of the tree, and manually search through its nodes for the ones
-we are looking for, but that is a bit inconvenient. To be able to efficiently
-utilize such an approach, we would need to make our own framework for traversing
-the tree and visiting only the types of nodes we are after. Luckily, this
-functionality is already provided in Eclipse, by its
+So far, the only thing that has been addressed is how the data that is going to
+be the basis for our analysis is structured. Another aspect of it is how we are
+going to traverse the AST to gather the information we need, so we can conclude
+about the properties we are analysing. It is of course possible to start at the
+top of the tree, and manually search through its nodes for the ones we are
+looking for, but that is a bit inconvenient. To be able to efficiently utilize
+such an approach, we would need to make our own framework for traversing the
+tree and visiting only the types of nodes we are after. Luckily, this
+functionality is already provided in \name{Eclipse}, by its
\typewithref{org.eclipse.jdt.core.dom}{ASTVisitor}.
-The Eclipse AST, together with its \type{ASTVisitor}, follows the \emph{Visitor}
-pattern\citing{designPatterns}. The intent of this design pattern is to
-facilitate extending the functionality of classes without touching the classes
-themselves.
+The \name{Eclipse} AST, together with its \type{ASTVisitor}, follows the
+\pattern{Visitor} pattern\citing{designPatterns}. The intent of this design
+pattern is to facilitate extending the functionality of classes without touching
+the classes themselves.
-Let us say that there is a class hierarchy of \emph{Elements}. These elements
-all have a method \method{accept(Visitor visitor)}. In its simplest form, the
+Let us say that there is a class hierarchy of elements. These elements all have
+a method \method{accept(Visitor visitor)}. In its simplest form, the
\method{accept} method just calls the \method{visit} method of the visitor with
itself as an argument, like this: \code{visitor.visit(this)}. For the visitors
to be able to extend the functionality of all the classes in the elements
The use of the visitor pattern can be appropriate when the hierarchy of elements
is mostly stable, but the family of operations over its elements is constantly
-growing. This is clearly the cas for the Eclipse AST, since the hierarchy of
+growing. This is clearly the case for the \name{Eclipse} AST, since the hierarchy of
type \type{ASTNode} is very stable, but the functionality of its elements is
extended every time someone needs to operate on the AST. Another aspect of the
-Eclipse implementation is that it is a public API, and the visitor pattern is an
+\name{Eclipse} implementation is that it is a public API, and the visitor pattern is an
easy way to provide access to the nodes in the tree.
-The version of the visitor pattern implemented for the AST nodes in Eclipse also
+The version of the visitor pattern implemented for the AST nodes in \name{Eclipse} also
provides an elegant way to traverse the tree. It does so by following the
convention that every node in the tree first let the visitor visit itself,
before it also makes all its children accept the visitor. The children are only
\subsection{The PrefixesCollector}
The \typewithref{no.uio.ifi.refaktor.extractors.collectors}{PrefixesCollector}
finds prefixes that makes up the basis for calculating move targets for the
-Extract and Move Method refactoring. It visits expression
+\refa{Extract and Move Method} refactoring. It visits expression
statements\typeref{org.eclipse.jdt.core.dom.ExpressionStatement} and creates
prefixes from its expressions in the case of method invocations. The prefixes
found is registered with a prefix set, together with all its sub-prefixes.
\subsection{The UnfixesCollector}\label{unfixes}
The \typewithref{no.uio.ifi.refaktor.extractors.collectors}{UnfixesCollector}
-finds unfixes within a selection. That is prefixes that cannot be used as a
-basis for finding a move target in a refactoring.
-
-An unfix can be a name that is assigned to within a selection. The reason that
-this cannot be allowed, is that the result would be an assignment to the
-\type{this} keyword, which is not valid in Java \see{eclipse_bug_420726}.
-
-Prefixes that originates from variable declarations within the same selection
-are also considered unfixes. This is because when a method is moved, it needs to
-be called through a variable. If this variable is also within the method that is
-to be moved, this obviously cannot be done.
-
-Also considered as unfixes are variable references that are of types that is not
-suitable for moving a methods to. This can be either because it is not
-physically possible to move the method to the desired class or that it will
-cause compilation errors by doing so.
-
-If the type binding for a name is not resolved it is considered and unfix. The
-same applies to types that is only found in compiled code, so they have no
-underlying source that is accessible to us. (E.g. the \type{java.lang.String}
-class.)
-
-Interfaces types are not suitable as targets. This is simply because interfaces
-in java cannot contain methods with bodies. (This thesis does not deal with
-features of Java versions later than Java 7. Java 8 has interfaces with default
-implementations of methods.) Neither are local types allowed. This accounts for
-both local and anonymous classes. Anonymous classes are effectively the same as
-interface types with respect to unfixes. Local classes could in theory be used
-as targets, but this is not possible due to limitations of the implementation of
-the Extract and Move Method refactoring. The problem is that the refactoring is
-done in two steps, so the intermediate state between the two refactorings would
-not be legal Java code. In the case of local classes, the problem is that, in
-the intermediate step, a selection referencing a local class would need to take
-the local class as a parameter if it were to be extracted to a new method. This
-new method would need to live in the scope of the declaring class of the
-originating method. The local class would then not be in the scope of the
-extracted method, thus bringing the source code into an illegal state. One could
-imagine that the method was extracted and moved in one operation, without an
-intermediate state. Then it would make sense to include variables with types of
-local classes in the set of legal targets, since the local classes would then be
-in the scopes of the method calls. If this makes any difference for software
-metrics that measure coupling would be a different discussion.
-
-\begin{listing}
-\begin{multicols}{2}
-\begin{minted}[]{java}
-// Before
-void declaresLocalClass() {
- class LocalClass {
- void foo() {}
- void bar() {}
- }
-
- LocalClass inst =
- new LocalClass();
- inst.foo();
- inst.bar();
-}
-\end{minted}
-
-\columnbreak
-
-\begin{minted}[]{java}
-// After Extract Method
-void declaresLocalClass() {
- class LocalClass {
- void foo() {}
- void bar() {}
- }
-
- LocalClass inst =
- new LocalClass();
- fooBar(inst);
-}
-
-// Intermediate step
-void fooBar(LocalClass inst) {
- inst.foo();
- inst.bar();
-}
-\end{minted}
-\end{multicols}
-\caption{When Extract and Move Method tries to use a variable with a local type
-as the move target, an intermediate step is taken that is not allowed. Here:
-\type{LocalClass} is not in the scope of \method{fooBar} in its intermediate
-location.}
-\label{lst:extractMethod_LocalClass}
-\end{listing}
+finds unfixes within a selection.
+\todoin{Give more technical detail?}
-The last class of names that are considered unfixes is names used in null tests.
-These are tests that reads like this: if \texttt{<name>} equals \var{null} then
-do something. If allowing variables used in those kinds of expressions as
-targets for moving methods, we would end up with code containing boolean
-expressions like \texttt{this == null}, which would not be meaningful, since
-\var{this} would never be \var{null}.
\subsection{The ContainsReturnStatementCollector}
+\todoin{Remove section?}
The
\typewithref{no.uio.ifi.refaktor.analyze.collectors}{ContainsReturnStatementCollector}
is a very simple property collector. It only visits the return statements within
The \typewithref{no.uio.ifi.refaktor.analyze.collectors}{LastStatementCollector}
collects the last statement of a selection. It does so by only visiting the top
level statements of the selection, and compares the textual end offset of each
-encuntered statement with the end offset of the previous statement found.
+encountered statement with the end offset of the previous statement found.
\section{Checkers}\label{checkers}
-The checkers are a range of classes that checks that selections complies with
-certian criterias. If a
+The checkers are a range of classes that checks that text selections complies
+with certain criteria. All checkers operates under the assumption that the code
+they check is free from compilation errors. If a
\typewithref{no.uio.ifi.refaktor.analyze.analyzers}{Checker} fails, it throws a
\type{CheckerException}. The checkers are managed by the
\type{LegalStatementsChecker}, which does not, in fact, implement the
it, and reports that all statements are considered legal if no
\type{CheckerException} is thrown. Many of the checkers either extends the
\type{PropertyCollector} or utilizes one or more property collectors to verify
-some criterias. The checkers registered with the \type{LegalStatementsChecker}
+some criteria. The checkers registered with the \type{LegalStatementsChecker}
are described next. They are run in the order presented below.
+\subsection{The CallToProtectedOrPackagePrivateMethodChecker}
+This checker is used to check that at selection does not contain a call to a
+method that is protected or package-private. Such a method either has the access
+modifier \code{protected} or it has no access modifier.
+
+The workings of the \type{CallToProtectedOrPackagePrivateMethod\-Checker} is
+very simple. It looks for calls to methods that are either protected or
+package-private within the selection, and throws an
+\type{IllegalExpressionFoundException} if one is found.
+
+\subsection{The DoubleClassInstanceCreationChecker}
+The \type{DoubleClassInstanceCreationChecker} checks that there are no double
+class instance creations where the inner constructor call take and argument that
+is built up using field references.
+
+The checker visits all nodes of type \type{ClassInstanceCreation} within a
+selection. For all of these nodes, if its parent also is a class instance
+creation, it accepts a visitor that throws a
+\type{IllegalExpressionFoundException} if it encounters a name that is a field
+reference.
+
+\subsection{The InstantiationOfNonStaticInnerClassChecker}
+The \type{InstantiationOfNonStaticInnerClassChecker} checks that selections
+does not contain instantiations of non-static inner classes. The
+\type{MoveInstanceMethodProcessor} in \name{Eclipse} does not handle such
+instantiations gracefully when moving a method. This problem is also related to
+bug\ldots \todoin{File Eclipse bug report}
+
\subsection{The EnclosingInstanceReferenceChecker}
-The purpose of this checker is to verify that the names in a selection is not
-referencing any enclosing instances. This is for making sure that all references
-is legal in a method that is to be moved. Theoretically, some situations could
-be easily solved my passing a reference to the referenced class with the moved
-method (e.g. when calling public methods), but the dependency on the
+The purpose of this checker is to verify that the names in a text selection are
+not referencing any enclosing instances. In theory, the underlying problem could
+be solved in some situations, but our dependency on the
\type{MoveInstanceMethodProcessor} prevents this.
The
\typewithref{no.uio.ifi.refaktor.analyze.analyzers}{EnclosingInstanceReferenceChecker}
is a modified version of the
-\typewithref{org.eclipse.jdt.internal.corext.refactoring.structure.MoveInstanceMethodProcessor}{EnclosingInstanceReferenceFinder}
+\typewithref{org.eclipse.jdt.internal.corext.refactoring.structure.MoveInstanceMethod\-Processor}{EnclosingInstanceReferenceFinder}
from the \type{MoveInstanceMethodProcessor}. Wherever the
-\type{EnclosingInstanceReferenceFinder} would create a fatal error status, the
-checker throws a \type{CheckerException}.
+\type{EnclosingInstanceReferenceFinder} would create a fatal error status, the
+checker will throw a \type{CheckerException}.
-It works by first finding all of the enclosing types of a selection. Thereafter
-it visits all its simple names to check that they are not references to
-variables or methods declared in any of the enclosing types. In addition the
-checker visits \var{this}-expressions to verify that no such expressions is
-qualified with any name.
+The checker works by first finding all of the enclosing types of a selection.
+Thereafter, it visits all the simple names of the selection to check that they
+are not references to variables or methods declared in any of the enclosing
+types. In addition, the checker visits \var{this}-expressions to verify that no
+such expressions are qualified with any name.
\subsection{The ReturnStatementsChecker}\label{returnStatementsChecker}
-\todoin{Write\ldots/change implementation/use control flow graph?}
+The checker for return statements is meant to verify that a text selection is
+consistent regarding return statements.
+
+If the selection is free from return statements, then the checker validates. So
+this is the first thing the checker investigates.
+
+If the checker proceeds any further, it is because the selection contains one
+or more return statements. The next test is therefore to check if the last
+statement of the selection ends in either a return or a throw statement. The
+responsibility for checking that the last statement of the selection eventually
+ends in a return or throw statement, is put on the
+\type{LastStatementOfSelectionEndsInReturnOrThrowChecker}. For every node
+visited, if the node is a statement, it does a test to see if the statement is a
+return, a throw or if it is an implicit return statement. If this is the case,
+no further checking is done. This checking is done in the \code{preVisit2}
+method \see{astVisitor}. If the node is not of a type that is being handled by
+its type-specific visit method, the checker performs a simple test. If the node
+being visited is not the last statement of its parent that is also enclosed by
+the selection, an \type{IllegalStatementFoundException} is thrown. This ensures
+that all statements are taken care of, one way or the other. It also ensures
+that the checker is conservative in the way it checks for legality of the
+selection.
+
+To examine if a statement is an implicit return statement, the checker first
+finds the last statement declared in its enclosing method. If this statement is
+the same as the one under investigation, it is considered an implicit return
+statement. If the statements are not the same, the checker does a search to see
+if the statement examined is also the last statement of the method that can be
+reached. This includes the last statement of a block statement, a labeled
+statement, a synchronized statement or a try statement, that in turn is the last
+statement enclosed by one of the statement types listed. This search goes
+through all the parents of a statement until a statement is found that is not
+one of the mentioned acceptable parent statements. If the search ends in a
+method declaration, then the statement is considered to be the last reachable
+statement of the method, and thus it is an implicit return statement.
+
+There are two kinds of statements that are handled explicitly: If-statements and
+try-statements. Block, labeled and do-statements are handled by fall-through to
+the other two.
+
+If-statements are handled explicitly by overriding their type-specific visit
+method. If the then-part does not contain any return or throw statements an
+\type{IllegalStatementFoundException} is thrown. If it does contain a return or
+throw, its else-part is checked. If the else-part is non-existent, or it does
+not contain any return or throw statements an exception is thrown. If no
+exception is thrown while visiting the if-statement, its children are visited.
+
+A try-statement is checked very similar to an if-statement. Its body must
+contain a return or throw. The same applies to its catch clauses and finally
+body. Failure to validate produces an \type{IllegalStatementFoundException}.
+
+If the checker does not complain at any point, the selection is considered valid
+with respect to return statements.
\subsection{The AmbiguousReturnValueChecker}
-This checker verifies that there are no \emph{ambiguous return statements} in a
-selection. The problem with ambiguous return statements arise when a selection
-is chosen to be extracted into a new method, but it needs to return more than
-one value from that method. This problem occurs in two situations. The first
-situation arise when there is more than one local variable that is both assigned
-to within a selection and also referenced after the selection. The other
-situation occur when there is only one such assignment, but there is also one or
-more return statements in the selection.
-
-First the checker needs to collect some data. Those data are the binding keys
+This checker verifies that there are no ambiguous return values in a selection.
+
+First, the checker needs to collect some data. Those data are the binding keys
for all simple names that are assigned to within the selection, including
variable declarations, but excluding fields. The checker also collects whether
there exists a return statement in the selection or not. No further checks of
After the binding keys of the assignees are collected, the checker searches the
part of the enclosing method that is after the selection for references whose
-binding keys are among the the collected keys. If more than one unique referral
-is found, or only one referral is found, but the selection also contains a
-return statement, we have a situation with an ambiguous return value, and an
-exception is thrown.
+binding keys are among the collected keys. If more than one unique referral is
+found, or only one referral is found, but the selection also contains a return
+statement, we have a situation with an ambiguous return value, and an exception
+is thrown.
%\todoin{Explain why we do not need to consider variables assigned inside
%local/anonymous classes. (The referenced variables need to be final and so
\subsection{The IllegalStatementsChecker}
This checker is designed to check for illegal statements.
-Any use of the \var{super} keyword is prohibited, since its meaning is altered
-when moving a method to another class.
+Notice that labels in break and continue statements needs some special
+treatment. Since a label does not have any binding information, we have to
+search upwards in the AST to find the \type{LabeledStatement} that corresponds
+to the label from the break or continue statement, and check that it is
+contained in the selection. If the break or continue statement does not have a
+label attached to it, it is checked that its innermost enclosing loop or switch
+statement (break statements only) also is contained in the selection.
-For a \emph{break} statement, there is two situations to consider: A break
-statement with or without a label. If the break statement has a label, it is
-checked that whole of the labeled statement is inside the selection. Since a
-label does not have any binding information, we have to search upwards in the
-AST to find the \type{LabeledStatement} that corresponds to the label from the
-break statement, and check that it is contained in the selection. If the break
-statement does not have a label attached to it, it is checked that its innermost
-enclosing loop or switch statement also is inside the selection.
+\todoin{Follow the development in the semantics section\ldots}
-The situation for a \emph{continue} statement is the same as for a break
-statement, except that it is not allowed inside switch statements.
+\chapter{Case Studies}
+
+In this chapter I am going to present a few case studies. This is done to give
+an impression of how the search-based \ExtractAndMoveMethod refactoring
+performs when giving it a larger project to take on. I will try to answer where
+it lacks, in terms of completeness, as well as showing its effect on refactored
+source code.
+
+The first and primary case, is refactoring source code from the \name{Eclipse
+JDT UI} project. The project is chosen because it is a real project, still in
+development, with a large code base that is written by many different people
+through several years. The code is installed in thousands of \name{Eclipse}
+applications worldwide, and must be seen as a good representative for
+professionally written Java source code. It is also the home for most of the JDT
+refactoring code.
+
+For the second case, the \ExtractAndMoveMethod refactoring is fed the
+\code{no.uio.ifi.refaktor} project. This is done as a variation of the
+``dogfooding'' methodology, where you use your own tools to do your job, also
+referred to as ``eating your own dog
+food''\citing{harrisonDogfooding2006}.
+
+\section{The tools}
+For conducting these experiments, three tools are used. Two of the ``tools''
+both uses Eclipse as their platform. The first is our own tool,
+written to be able to run the \ExtractAndMoveMethod refactoring as a batch
+process, analyzing and refactoring many methods after each other. The second is
+JUnit, that is used for running the projects own unit tests on the target code
+both before and after it is refactored. The last tool that is used is a code
+quality management tool, called \name{SonarQube}. It can be used to perform
+different tasks for assuring code quality, but we are only going to take
+advantage of one of its main features, namely Quality profiles.
+
+A quality profile is used to define a set of coding rules that a project is
+supposed to comply with. Failure to following these rules will be recorded as
+so-called ``issues'', marked as having one of several degrees of severities,
+ranging from ``info'' to ``blocker'', where the latter one is the most severe.
+The measurements done for these case studies are therefore not presented as
+fine-grained software metrics results, but rather as the number of issues for
+each defined rule.
+
+In addition to the coding rules defined through quality profiles, \name{SonarQube}
+calculates the complexity of source code. The metric that is used is cyclomatic
+complexity, developed by Thomas J. McCabe in
+1976\citing{mccabeComplexity1976}. In this metric, functions have an initial
+complexity of 1, and whenever the control flow of a function splits, the
+complexity increases by
+one\footnote{\url{http://docs.codehaus.org/display/SONAR/Metric+definitions}}.
+\name{SonarQube} discriminates between functions and accessors. Accessors
+are methods that are recognized as setters or getters. Accessors are not counted
+in the complexity analysis.
+
+\section{The \name{SonarQube} quality profile}
+The quality profile that is used with \name{SonarQube} in these case studies has got
+the name \name{IFI Refaktor Case Study} (version 6). The rules defined in the
+profile are chosen because they are the available rules found in \name{SonarQube} that
+measures complexity and coupling. Now follows a description of the rules in the
+quality profile. The values that are set for these rules are listed in
+\myref{tab:qualityProfile1}.
-Regarding \emph{assignments}, two types of assignments is allowed: Assignment to
-a non-final variable and assignment to an array access. All other assignments is
-regarded illegal.
+\begin{description}
+ \item[Avoid too complex class] is a rule that measures cyclomatic complexity
+ for every statement in the body of a class, except for setters and getter.
+ The threshold value set is its default value of 200.
+
+ \item[Classes should not be coupled to too many other classes ] is a rule that
+ measures how many other classes a class depends upon. It does not count the
+ dependencies of nested classes. It is meant to promote the Single
+ Responsibility Principle. Although not explicitly stated, the rule's metric
+ resembles the \metr{Coupling between object classes} (CBO) metric that is
+ described by Chidamber and Kemerer in their article \tit{A Metrics Suite for
+ Object Oriented Design}\citing{metricsSuite1994}. The max value for the rule
+ is chosen on the background of an empirical study by Raed Shatnawi, that
+ concludes that the number 9 is the most useful threshold for the CBO
+ metric\citing{shatnawiQuantitative2010}. This study is also performed on
+ Eclipse source code, so this threshold value should be particularly well
+ suited for the Eclipse JDT UI case in this chapter.
+
+ \item[Control flow statements \ldots{} should not be nested too deeply] is
+ a rule that is meant to counter ``Spaghetti code''. It measures the nesting
+ level of if, for, while, switch and try statements. The nesting levels start
+ at 1. The max value set is its default value of 3.
+
+ \item[Methods should not be too complex] is a rule that measures cyclomatic
+ complexity the same way as the ``Avoid too complex class'' rule. The max
+ value used is 10, which ``seems like a reasonable, but not magical, upper
+ limit``\citing{mccabeComplexity1976}.
+
+ \item[Methods should not have too many lines] is a rule that simply measures
+ the number of lines in methods. The threshold value of 20 is used for this
+ metric. This is based on my own subjective opinions, as the default value of
+ 100 seems a bit too loose.
+
+ \item[NPath Complexity] is a rule that measures the number of possible
+ execution paths through a function. The value used is the default value of
+ 200, that seems like a recognized threshold for this metric.
+
+ \item[Too many methods] is a rule that measures the number of methods in a
+ class. The threshold value used is the default value of 10.
+
+\end{description}
+
+
+\begin{table}[htb]
+ \caption{The \name{IFI Refaktor Case Study} quality profile (version 6).}
+ \label{tab:qualityProfile1}
+ \centering
+ \begin{tabularx}{\textwidth}{@{}>{\bfseries}L{1.5}R{0.5}@{}}
+ \toprule
+ \textbf{Rule} & \textbf{Max value} \\
+ \midrule
+ Avoid too complex class & 200 \\
+ Classes should not be coupled to too many other classes (Single
+ Responsibility Principle) & 9 \\
+ Control flow statements \ldots{} should not be nested too deeply &
+ 3 \\
+ Methods should not be too complex & 10 \\
+ Methods should not have too many lines & 20 \\
+ NPath Complexity & 200 \\
+ Too many methods & 10 \\
+
+ \bottomrule
+ \end{tabularx}
+\end{table}
+
+\section{The input}
+A precondition for the source code that is going to be the target for a series
+of \ExtractAndMoveMethod refactorings, is that it is organized as an Eclipse
+project. It is also assumed that the code is free from compilation errors.
+
+\section{The experiment}
+For a given project, the first job that is done, is to refactor its source code.
+The refactoring batch job produces three things: The refactored project,
+statistics gathered during the execution of the series of refactorings, and an
+error log describing any errors happening during this execution. See
+\myref{sec:benchmarking} for more information about how the refactorings are
+performed.
+
+After the refactoring process is done, the before- and after-code is analyzed
+with \name{SonarQube}. The analysis results are then stored in a database and
+displayed through a \name{SonarQube} server with a web interface.\todoin{How
+long are these results going to be publicly available?}
+
+The before- and after-code is also tested with their own unit tests. This is
+done to discover any changes in the semantic behavior of the refactored code,
+within the limits of these tests.
+
+\section{Case 1: The Eclipse JDT UI project}
+This case is the ultimate test for our \ExtractAndMoveMethod refactoring. The
+target source code is massive. With its over 300,000 lines of code and over
+25,000 methods, it is formidable task to perform automated changes on it. There
+should be plenty of situations where things can go wrong, and, as we shall see
+later, they do.
+
+I will start by presenting some statistics from the refactoring execution,
+before I pick apart the \name{SonarQube} analysis and conclude by commenting on
+the results from the unit tests. The configuration for the experiment is
+specified in \myref{tab:configurationCase1}.
+
+\begin{table}[htb]
+ \caption{Configuration for Case 1.}
+ \label{tab:configurationCase1}
+ \centering
+ \begin{tabularx}{\textwidth}{@{}>{\bfseries}L{0.67}L{1.33}@{}}
+ \toprule
+ \spancols{2}{Benchmark data} \\
+ \midrule
+ Launch configuration & CaseStudy.launch \\
+ Project & no.uio.ifi.refaktor.benchmark \\
+ Repository & gitolite@git.uio.no:ifi-stolz-refaktor \\
+ Commit & 43c16c04520746edd75f8dc2a1935781d3d9de6c \\
+ \midrule
+ \spancols{2}{Input data} \\
+ \midrule
+ Project & org.eclipse.jdt.ui \\
+ Repository & git://git.eclipse.org/gitroot/jdt/eclipse.jdt.ui.git \\
+ Commit & f218388fea6d4ec1da7ce22432726c244888bb6b \\
+ Branch & R3\_8\_maintenance \\
+ Tests suites & org.eclipse.jdt.ui.tests.AutomatedSuite,
+ org.eclipse.jdt.ui.tests.refactoring.all.\-AllAllRefactoringTests \\
+
+ \bottomrule
+ \end{tabularx}
+\end{table}
+\subsection{Statistics}
+The statistics gathered during the refactoring execution is presented in
+\myref{tab:case1Statistics}.
+
+\begin{table}[htb]
+ \caption{Statistics after batch refactoring the Eclipse JDT UI project with
+ the \ExtractAndMoveMethod refactoring.}
+ \label{tab:case1Statistics}
+ \centering
+ \begin{tabularx}{\textwidth}{@{}>{\bfseries}L{1.5}R{0.5}@{}}
+ \toprule
+ \spancols{2}{Time used} \\
+ \midrule
+ Total time & 98m38s \\
+ Analysis time & 14m41s (15\%) \\
+ Change time & 74m20s (75\%) \\
+ Miscellaneous tasks & 9m37s (10\%) \\
+ \midrule
+ \spancols{2}{Numbers of each type of entity analyzed} \\
+ \midrule
+ Packages & 110 \\
+ Compilation units & 2,097 \\
+ Types & 3,152 \\
+ Methods & 27,667 \\
+ Text selections & 591,500 \\
+ \midrule
+ \spancols{2}{Numbers for \ExtractAndMoveMethod refactoring candidates} \\
+ \midrule
+ Methods chosen as candidates & 2,552 \\
+ Methods NOT chosen as candidates & 25,115 \\
+ Candidate selections (multiple per method) & 36,843 \\
+ \midrule
+ \spancols{2}{\ExtractAndMoveMethod refactorings executed} \\
+ \midrule
+ Fully executed & 2,469 \\
+ Not fully executed & 83 \\
+ Total attempts & 2,552 \\
+ \midrule
+ \spancols{2}{Primitive refactorings executed} \\
+ \spancols{2}{\small \ExtractMethod refactorings} \\
+ \midrule
+ Performed & 2,483 \\
+ Not performed & 69 \\
+ Total attempts & 2,552 \\
+ \midrule
+ \spancols{2}{\small \MoveMethod refactorings} \\
+ \midrule
+ Performed & 2469 \\
+ Not performed & 14 \\
+ Total attempts & 2,483 \\
+
+ \bottomrule
+ \end{tabularx}
+\end{table}
+
+\subsubsection{Execution time}
+I consider the total execution time of approximately 1.5 hours as being
+acceptable. It clearly makes the batch process unsuitable for doing any
+on-demand analysis or changes, but it is good enough for running periodic jobs,
+like over-night analysis.
+
+As the statistics show, 75\% of the total time goes into making the actual code
+changes. The time consumers are here the primitive \ExtractMethod and
+\MoveMethod refactorings. Included in the change time is the parsing and
+precondition checking done by the refactorings, as well as textual changes done
+to files on disk. All this parsing and disk access is time-consuming, and
+constitute a large part of the change time.
+
+In comparison, the pure analysis time, used to find suitable candidates, only
+make up for 15\% of the total time consumed. This includes analyzing almost
+600,000 text selections, while the number of attempted executions of the
+\ExtractAndMoveMethod refactoring are only about 2,500. So the number of
+executed primitive refactorings are approximately 5,000. Assuming the time used
+on miscellaneous tasks are used mostly for parsing source code for the analysis,
+we can say that the time used for analyzing code is at most 25\% of the total
+time. This means that for every primitive refactoring executed, we can analyze
+around 360 text selections. So, with an average of about 21 text selections per
+method, it is reasonable to say that we can analyze over 15 methods in the time
+it takes to perform a primitive refactoring.
+
+\subsubsection{Refactoring candidates}
+Out of the 27,667 methods that was analyzed, 2,552 methods contained selections
+that was considered candidates for the \ExtractAndMoveMethod refactoring. This
+is roughly 9\% off the methods in the project. These 9\% of the methods had on
+average 14.4 text selections that was considered considered possible refactoring
+candidates.
+
+\subsubsection{Executed refactorings}
+2,469 out of 2,552 attempts on executing the \ExtractAndMoveMethod refactoring
+was successful, giving a success rate of 96.7\%. The failure rate of 3.3\% stem
+from situations where the analysis finds a candidate selection, but the change
+execution fails. This failure could be an exception that was thrown, and the
+refactoring aborts. It could also be the precondition checking for one of the
+primitive refactorings that gives us an error status, meaning that if the
+refactoring proceeds, the code will contain compilation errors afterwards,
+forcing the composite refactoring to abort. This means that if the
+\ExtractMethod refactoring fails, no attempt is done for the \MoveMethod
+refactoring. \todo{Redundant information? Put in benchmark chapter?}
+
+Out of the 2,552 \ExtractMethod refactorings that was attempted executed, 69 of
+them failed. This give a failure rate of 2.7\% for the primitive refactoring. In
+comparison, the \MoveMethod refactoring had a failure rate of 0.6 \% of the
+2,483 attempts on the refactoring.
+
+\subsection{\name{SonarQube} analysis}
+Results from the \name{SonarQube} analysis is shown in
+\myref{tab:case1ResultsProfile1}.
+
+\begin{table}[htb]
+ \caption{Results for analyzing the Eclipse JDT UI project, before and after
+ the refactoring, with \name{SonarQube} and the \name{IFI Refaktor Case Study}
+ quality profile. (Bold numbers are better.)}
+ \label{tab:case1ResultsProfile1}
+ \centering
+ \begin{tabularx}{\textwidth}{@{}>{\bfseries}L{1.5}R{0.25}R{0.25}@{}}
+ \toprule
+ \textnormal{Number of issues for each rule} & Before & After \\
+ \midrule
+ Avoid too complex class & 81 & \textbf{79} \\
+ Classes should not be coupled to too many other classes (Single
+ Responsibility Principle) & \textbf{1,098} & 1,199 \\
+ Control flow statements \ldots{} should not be nested too deeply & 1,375 &
+ \textbf{1,285} \\
+ Methods should not be too complex & 1,518 & \textbf{1,452} \\
+ Methods should not have too many lines & 3,396 & \textbf{3,291} \\
+ NPath Complexity & 348 & \textbf{329} \\
+ Too many methods & \textbf{454} & 520 \\
+ \midrule
+ Total number of issues & 8,270 & \textbf{8,155} \\
+ \midrule
+ \midrule
+ \spancols{3}{Complexity} \\
+ \midrule
+ Per function & 3.6 & \textbf{3.3} \\
+ Per class & \textbf{29.5} & 30.4 \\
+ Per file & \textbf{44.0} & 45.3 \\
+ \midrule
+ Total complexity & \textbf{84,765} & 87,257 \\
+ \midrule
+ \midrule
+ \spancols{3}{Numbers of each type of entity analyzed} \\
+ \midrule
+ Files & 1,926 & 1,926 \\
+ Classes & 2,875 & 2,875 \\
+ Functions & 23,744 & 26,332 \\
+ Accessors & 1,296 & 1,019 \\
+ Statements & 162,768 & 165,145 \\
+ Lines of code & 320,941 & 329,112 \\
+ \midrule
+ Technical debt (in days) & \textbf{1,003.4} & 1,032.7 \\
+ \bottomrule
+ \end{tabularx}
+\end{table}
+
+\subsubsection{Diversity in the number of entities analyzed}
+The analysis performed by \name{SonarQube} is reporting fewer methods than found
+by the pre-refactoring analysis. \name{SonarQube} discriminates between
+functions (methods) and accessors, so the 1,296 accessors play a part in this
+calculation. \name{SonarQube} also has the same definition as our plugin when
+it comes to how a class is defined. Therefore is seems like \name{SonarQube}
+misses 277 classes that our plugin handles. This can explain why the {SonarQube}
+report differs from our numbers by approximately 2,500 methods,
+
+\subsubsection{Complexity}
+On all complexity rules that works on the method level, the number of issues
+decreases with between 3.1\% and 6.5\% from before to after the refactoring. The
+average complexity of a method decreases from 3.6 to 3.3, which is an
+improvement of about 8.3\%. So, on the method level, the refactoring must be
+said to have a slightly positive impact.
+
+The improvement in complexity on the method level is somewhat traded for
+complexity on the class level. The complexity per class metric is worsen by 3\%
+from before to after. The issues for the ``Too many methods'' rule also
+increases by 14.5\%. These numbers indicate that the refactoring makes quite a
+lot of the classes a little more complex overall. This is the expected outcome,
+since the \ExtractAndMoveMethod refactoring introduces almost 2,500 new methods
+into the project.
+
+The only number that can save the refactoring's impact on complexity on the
+class level, is the ``Avoid too complex class'' rule. It improves with 2.5\%,
+thus indicating that the complexity is moderately better distributed between the
+classes after the refactoring than before.
+
+\subsubsection{Coupling}
+One of the hopes when starting this project, was to be able to make a
+refactoring that could lower the coupling between classes. Better complexity at
+the method level is a not very unexpected byproduct of dividing methods into
+smaller parts. Lowering the coupling on the other hand, is a far greater task.
+This is also reflected in the results for the only coupling rule defined in the
+\name{SonarQube} quality profile, namely the ``Classes should not be coupled to
+too many
+other classes (Single Responsibility Principle)'' rule.
+
+The number of issues for the coupling rule is 1,098 before the refactoring, and
+1,199 afterwards. This is an increase in issues of 9.2\%, and a blow for this
+project. These numbers can be interpreted two ways. The first possibility is
+that our assumptions are wrong, and that increasing indirection does not
+decrease coupling between classes. The other possibility is that our analysis
+and choices of candidate text selections are not good enough. I vote for the
+second possibility. (Voting against the public opinion may also be a little
+bold.)
+
+What probably happens is, that many of the times the \ExtractAndMoveMethod
+refactoring is performed, the \MoveMethod refactoring ``drags'' with it
+references to classes that are unknown to the method destination. If it happens
+to be so lucky that it removes a dependency from one class, it might as well
+introduce three new dependencies to another class. In those situations that a
+class does not know about the originating class of a moved method, the
+\MoveMethod refactoring most certainly will introduce a dependency. This is
+because there is a
+bug\footnote{\url{https://bugs.eclipse.org/bugs/show\_bug.cgi?id=228635}} in the
+refactoring, making it pass an instance of the originating class as a reference
+to the moved method, regardless of whether the reference is used in the method
+body or not.
+
+There is also the possibility that the heuristics used to find candidate text
+selections are not good enough, they most certainly are not. I wish I had more
+time to fine-tune them, and to complete the analysis part of the project, but
+this is simply not the case. This becomes even clearer when analyzing the unit
+test results for the after-code.
+
+\subsubsection{Totals}
+On the bright side, the total number of issues is lower after the refactoring
+than it was before. Before the refactoring, the total number of issues is
+8,270, and after it is 8,155. An improvement of only 1.4\%.
+
+Then \name{SonarQube} tells me that the total complexity has increased by
+2.9\%, and that the (more questionable) ``technical debt'' has increased from
+1,003.4 to 1,032.7 days, also a deterioration of 2.9\%. Although these numbers
+are similar, no correlation has been found between them.
+
+\subsection{Unit tests}
+The tests that have been run for the \name{Eclipse JDT UI} project, are the
+tests in the test suites specified as the main test suites on the JDT UI wiki
+page on how to contribute to the
+project\footnote{\url{https://wiki.eclipse.org/JDT\_UI/How\_to\_Contribute\#Unit\_Testing}}.
+
+\subsubsection{Before the refactoring}
+Running the tests for the before-code of Eclipse JDT UI yielded 4 errors and 3
+failures for the \type{AutomatedSuite} test suite (2,007 test cases), and 2
+errors and
+3 failures for the \type{AllAllRefactoringTests} test suite (3,816 test cases).
+
+\subsubsection{After the refactoring}
+The test results for the after-code of the Eclipse JDT UI project is another
+story. The reason for this is that during the setup for the unit tests, Eclipse
+now reports that the project contains 322 fatal errors, and a lot of errors that
+probably follows from these. This is another blow for this master's project.
+
+It has now been shown that the \ExtractAndMoveMethod refactoring, in its current
+state, produces code that does not compile. Had these errors originated from
+only one bug, it would not have been much of a problem, but this is not the
+case. By only looking at some random compilation problems in the refactored code,
+I came up with at least four different bugs \todo{write bug reports?} that
+caused those problems. I then stopped looking for more, since some of the bugs
+would take more time to fix than I could justify using on them at this point.
+
+The only thing that can be said in my defence, is that all the compilation
+errors could have been avoided if the type of situations that causes them was
+properly handled by the primitive refactorings, that again are supported by the
+Eclipse JDT UI project. All of the four randomly found bugs that I mentioned
+before, are also weaknesses of the \MoveMethod refactoring. If the primitive
+refactorings had detected the up-coming errors
+in their precondition checking phase, the refactorings would have been aborted,
+since this is how the \ExtractAndMoveMethod refactoring handles such situations.
+
+Of course, taking all possible situations into account is an immense task. This
+is one of the reasons for the failure. A complete analysis is too big of a task
+for this master's project to handle. Looking at it now, this comes as no
+surprise, since the task is obviously also too big for the creators of the
+primitive \MoveMethod refactoring. This shows that the underlying primitive
+refactorings are not complete enough to be fully relied upon for avoiding
+compilation errors.
+
+Considering all these problems, it is difficult to know how to interpret the
+unit test results from after refactoring the Eclipse JDT UI. The
+\type{AutomatedSuite} reported 565 errors and 5 failures. Three of the failures
+were the same as reported before the refactoring took place, so two of them are
+new. For these two cases it is not immediately apparent what makes them behave
+differently. The program is so complex that to analyze it to find this out, we
+might need more powerful methods than just manually analyzing its source code.
+This is somewhat characteristic for imperative programming: The programs are
+often hard to analyze and understand.
+
+For the \type{AllAllRefactoringTests} test suite, the three failures are gone,
+but the two errors have grown to 2,257 errors. I will not try to analyze those
+errors.
+
+What I can say, is that it is likely that the \ExtractAndMoveMethod refactoring
+has introduced some unintended behavioral changes. Let us say that the
+refactoring introduces at least two behavior-altering changes for every 2,500
+executions. More than that is difficult to say about the behavior-preserving
+properties of the \ExtractAndMoveMethod refactoring, at this point.
+
+\subsection{Conclusions}
+After automatically analyzing and executing the \ExtractAndMoveMethod
+refactoring for all the methods in the Eclipse JDT UI project, the results does
+not look that promising. For this case, the refactoring seems almost unusable as
+it is now. The error rate and measurements done tells us this.
+
+The refactoring makes the code a little less complex at the method level. But
+this is merely a side effect of extracting methods, and holds little scientific
+value. When it comes to the overall complexity, it is increased, although it is
+slightly better spread among the classes.
+
+The analysis done before the \ExtractAndMoveMethod refactoring, is currently not
+complete enough to make the refactoring useful. It introduces too many errors in
+the code, and the code may change it's behavior. It also remains to prove that
+large scale refactoring with it can decrease coupling between classes. A better
+analysis may prove this, but in its present state, the opposite is the fact. The
+coupling measurements done by \name{SonarQube} shows this.
+
+On the bright side, the performance of the refactoring process is not that bad.
+It shows that it is possible to make a tool the way we do, if we can make the
+tool do anything useful. As long as the analysis phase is not going to involve
+anything that uses to much disk access, a lot of analysis can be done in a
+reasonable amount of time.
+
+The time used on performing the actual changes excludes a trial and error
+approach with the tools used in this master's project. In a trial and error
+approach, you could for instance be using the primitive refactorings used in
+this project to refactor code, and only then make decisions based on the effect,
+possibly shown by traditional software metrics. The problem with the approach
+taken in this project, compared to a trial and error approach, is that using
+heuristics beforehand is much more complicated. But on the other hand, a trial
+and error approach would still need to face the challenges of producing code
+that does compile without errors. If using refactorings that could produce
+in-memory changes, a trial and error approach could be made more efficient.
+
+\section{Case 2: The \type{no.uio.ifi.refaktor} project}
+In this case we will see a form of the ``dogfooding'' methodology used, when
+refactoring our own \type{no.uio.ifi.refaktor} project with the
+\ExtractAndMoveMethod refactoring.
+
+In this case I will try to point out some differences from case 1, and how they
+impact the execution of the benchmark. The refaktor project is 39 times smaller
+than the Eclipse JDT UI project, measured in lines of code. This will make
+things a bit more transparent. It will therefore be interesting to see if this
+case can shed light on any aspect of our project that was lost in the larger
+case 1.
+
+The configuration for the experiment is specified in
+\myref{tab:configurationCase2}.
+
+\begin{table}[htb]
+ \caption{Configuration for Case 2.}
+ \label{tab:configurationCase2}
+ \centering
+ \begin{tabularx}{\textwidth}{@{}>{\bfseries}L{0.67}L{1.33}@{}}
+ \toprule
+ \spancols{2}{Benchmark data} \\
+ \midrule
+ Launch configuration & CaseStudyDogfooding.launch \\
+ Project & no.uio.ifi.refaktor.benchmark \\
+ Repository & gitolite@git.uio.no:ifi-stolz-refaktor \\
+ Commit & 43c16c04520746edd75f8dc2a1935781d3d9de6c \\
+ \midrule
+ \spancols{2}{Input data} \\
+ \midrule
+ Project & no.uio.ifi.refaktor \\
+ Repository & gitolite@git.uio.no:ifi-stolz-refaktor \\
+ Commit & 43c16c04520746edd75f8dc2a1935781d3d9de6c \\
+ Branch & master \\
+ Test configuration & no.uio.ifi.refaktor.tests/ExtractTest.launch \\
+ \bottomrule
+ \end{tabularx}
+\end{table}
+
+\subsection{Statistics}
+The statistics gathered during the refactoring execution is presented in
+\myref{tab:case2Statistics}.
-\todoin{Finish\ldots}
+\begin{table}[htb]
+ \caption{Statistics after batch refactoring the \type{no.uio.ifi.refaktor}
+project with the \ExtractAndMoveMethod refactoring.}
+ \label{tab:case2Statistics}
+ \centering
+ \begin{tabularx}{\textwidth}{@{}>{\bfseries}L{1.5}R{0.5}@{}}
+ \toprule
+ \spancols{2}{Time used} \\
+ \midrule
+ Total time & 1m15s \\
+ Analysis time & 0m18s (24\%) \\
+ Change time & 0m47s (63\%) \\
+ Miscellaneous tasks & 0m10s (14\%) \\
+ \midrule
+ \spancols{2}{Numbers of each type of entity analyzed} \\
+ \midrule
+ Packages & 33 \\
+ Compilation units & 154 \\
+ Types & 168 \\
+ Methods & 1,070 \\
+ Text selections & 8,609 \\
+ \midrule
+ \spancols{2}{Numbers for \ExtractAndMoveMethod refactoring candidates} \\
+ \midrule
+ Methods chosen as candidates & 58 \\
+ Methods NOT chosen as candidates & 1,012 \\
+ Candidate selections (multiple per method) & 227 \\
+ \midrule
+ \spancols{2}{\ExtractAndMoveMethod refactorings executed} \\
+ \midrule
+ Fully executed & 53 \\
+ Not fully executed & 5 \\
+ Total attempts & 58 \\
+ \midrule
+ \spancols{2}{Primitive refactorings executed} \\
+ \spancols{2}{\small \ExtractMethod refactorings} \\
+ \midrule
+ Performed & 56 \\
+ Not performed & 2 \\
+ Total attempts & 58 \\
+ \midrule
+ \spancols{2}{\small \MoveMethod refactorings} \\
+ \midrule
+ Performed & 53 \\
+ Not performed & 3 \\
+ Total attempts & 56 \\
+
+ \bottomrule
+ \end{tabularx}
+\end{table}
+\subsubsection{Differences}
+There are some differences between the two projects that make them a little
+difficult to compare by performance.
+
+\paragraph{Different complexity.}
+Although the JDT UI project is 39 times greater than the refaktor project in
+terms of lines of code, it is only about 26 times its size measured in numbers
+of methods. This means that the methods in the refaktor project are smaller in
+average than in the JDT project. This is also reflected in the \name{SonarQube}
+report, where the complexity per method for the JDT project is 3.6, while the
+refaktor project has a complexity per method of 2.1.
+
+\paragraph{Number of selections per method.}
+The analysis for the JDT project processed 21 text selections per method in
+average. This number for the refaktor project is only 8 selections per method
+analyzed. This is a direct consequence of smaller methods.
+
+\paragraph{Different candidates to methods ratio.}
+The differences in how the projects are factored are also reflected in the
+ratios for how many methods that are chosen as candidates compared to the total
+number of methods analyzed. For the JDT project, 9\% of the methods was
+considered to be candidates, while for the refaktor project, only 5\% of the
+methods was chosen.
+
+\paragraph{The average number of possible candidate selection.}
+For the methods that are chosen as candidates, the average number of possible
+candidate selections for these methods differ quite much. For the JDT project,
+the number of possible candidate selections for these methods were 14.44
+selections per method, while the candidate methods in the refaktor project had
+only 3.91 candidate selections to choose from, in average.
+
+\subsubsection{Execution time}
+The differences in complexity, and the different candidate methods to total
+number of methods ratios, is shown in the distributions of the execution times.
+For the JDT project, 75\% of the total time was used on the actual changes,
+while for the refaktor project, this number was only 63\%.
+
+For the JDT project, the benchmark used on average 0.21 seconds per method in
+the project, while for the refaktor project it used only 0.07 seconds per
+method. So the process used 3 times as much time per method for the JDT project
+than for the refaktor project.
+
+While the JDT project is 39 times larger than the refaktor project measured in
+lines of code, the benchmark used about 79 times as long time on it than for the
+refaktor project. Relatively, this is about twice as long.
+
+Since the details of these execution times are not that relevant to this
+master's project, only their magnitude, I will leave them here.
+
+\subsubsection{Executed refactorings}
+For the composite \ExtractAndMoveMethod refactoring performed in case 2, 53
+successful attempts out of 58 gives a success rate of 91.4\%. This is 5.3
+percentage points worse than for case 1.
+
+\subsection{\name{SonarQube} analysis}
+Results from the \name{SonarQube} analysis is shown in
+\myref{tab:case2ResultsProfile1}.
+
+Not much is to be said about these results. The trends in complexity and
+coupling are the same. We end up a little worse after the refactoring process
+than before.
+
+\begin{table}[htb]
+ \caption{Results for analyzing the \var{no.uio.ifi.refaktor} project, before
+ and after the refactoring, with \name{SonarQube} and the \name{IFI Refaktor
+ Case Study} quality profile. (Bold numbers are better.)}
+ \label{tab:case2ResultsProfile1}
+ \centering
+ \begin{tabularx}{\textwidth}{@{}>{\bfseries}L{1.5}R{0.25}R{0.25}@{}}
+ \toprule
+ \textnormal{Number of issues for each rule} & Before & After \\
+ \midrule
+ Avoid too complex class & 1 & 1 \\
+ Classes should not be coupled to too many other classes (Single
+ Responsibility Principle) & \textbf{29} & 34 \\
+ Control flow statements \ldots{} should not be nested too deeply & 24 &
+ \textbf{21} \\
+ Methods should not be too complex & 17 & \textbf{15} \\
+ Methods should not have too many lines & 41 & \textbf{40} \\
+ NPath Complexity & 3 & 3 \\
+ Too many methods & \textbf{13} & 15 \\
+ \midrule
+ Total number of issues & \textbf{128} & 129 \\
+ \midrule
+ \midrule
+ \spancols{3}{Complexity} \\
+ \midrule
+ Per function & 2.1 & 2.1 \\
+ Per class & \textbf{12.5} & 12.9 \\
+ Per file & \textbf{13.8} & 14.2 \\
+ \midrule
+ Total complexity & \textbf{2,089} & 2,148 \\
+ \midrule
+ \midrule
+ \spancols{3}{Numbers of each type of entity analyzed} \\
+ \midrule
+ Files & 151 & 151 \\
+ Classes & 167 & 167 \\
+ Functions & 987 & 1,045 \\
+ Accessors & 35 & 30 \\
+ Statements & 3,355 & 3,416 \\
+ Lines of code & 8,238 & 8,460 \\
+ \midrule
+ Technical debt (in days) & \textbf{19.0} & 20.7 \\
+ \bottomrule
+ \end{tabularx}
+\end{table}
-\chapter{Benchmarking}
-\todoin{Better name than ``benchmarking''?}
-This part of the master project is located in the Eclipse project
+\subsection{Unit tests}
+The tests used for this case are the same that has been developed throughout the
+master's project.
+
+The code that was refactored for this case suffered from some of the problems
+discovered in case 1. This means that the after-code for case 2 also contained
+compilation errors, but they were not as many. The code contained only 6 errors
+that made the code not compile.
+
+All of the errors made, originated from the same bug. It is a bug that happens
+in situation where a class instance creation is moved from between packages, and
+the class for the instance is package-private. The \MoveMethod refactoring does
+not detect that there will be a visibility problem, and neither does it promote
+the package-private class to be public.
+
+Since the errors was easy to fix manually, I corrected them and ran the unit
+tests as planned. Before the refactoring, all tests passed. All tests also
+passed after the refactoring, with the six error corrections. Since the
+corrections done is not of a kind that could make the behavior of the program
+change, it is likely that the refactorings done to the
+\type{no.uio.ifi.refaktor} project did not change its behavior. This is also
+supported by the informal experiment presented next.
+
+\subsection{An informal experiment}
+To complete the task of ``eating my own dog food'', I conducted an informal
+experiment where I used the refactored version of the \type{no.uio.ifi.refaktor}
+project, with the corrections, to again refaktor ``itself''.
+
+The experiment produced code containing the same six errors as after the
+previous experiment. I also compared the after-code from the two experiments
+with a diff-tool. The only differences found was different method names. This is
+expected, since the method names are randomly generated by the
+\ExtractAndMoveMethod refactoring.
+
+The outcome of this simple experiment makes me more confident that the
+\ExtractAndMoveMethod refactoring made only behavior-preserving changes to the
+\type{no.uio.ifi.refaktor} project, apart from the compilation errors.
+
+\subsection{Conclusions}
+The differences in complexity between the Eclipse JDT UI project and the
+\type{no.uio.ifi.refaktor} project, clearly influenced the differences in their
+execution times. This is mostly because fewer of the methods were chosen to be
+refactored for the refaktor project than for the JDT project. What this makes
+difficult, is to know if there are any severe performance penalties associated
+with refactoring on a large project compared to a small one.
+
+The trends in the \name{SonarQube} analysis are the same for this case as for
+the previous one. This gives more confidence in the these results.
+
+By refactoring our own code and using it again to refactor our code, we showed
+that it is possible to write an automated composite refactoring that works for
+many cases. That it probably did not alter the behavior of a smaller project
+shows us nothing more than that though, and might just be a coincidence.
+
+\section{Summary}
+\todoin{Write? Or wrap up in final conclusions?}
+
+\chapter{Benchmarking}\label{sec:benchmarking}
+This part of the master's project is located in the \name{Eclipse} project
\code{no.uio.ifi.refaktor.benchmark}. The purpose of it is to run the equivalent
of the \type{SearchBasedExtractAndMoveMethodChanger}
\see{searchBasedExtractAndMoveMethodChanger} over a larger software project,
-both to test its roubustness but also its effect on different software metrics.
+both to test its robustness but also its effect on different software metrics.
\section{The benchmark setup}
-The benchmark itself is set up as a \emph{JUnit} test case. This is a convenient
-setup, and utilizes the \emph{JUnit Plugin Test Launcher}. This provides us a
-with a fully functional Eclipse workbench. Most importantly, this gives us
-access to the Java Model of Eclipse \see{javaModel}.
+The benchmark itself is set up as a \name{JUnit} test case. This is a convenient
+setup, and utilizes the \name{JUnit Plugin Test Launcher}. This provides us with
+a fully functional \name{Eclipse} workbench. Most importantly, this gives us
+access to the Java Model of \name{Eclipse} \see{javaModel}.
\subsection{The ProjectImporter}
The Java project that is going to be used as the data for the benchmark, must be
import operation is run to perform the import.
I have found no simple API call to accomplish what the importer does, which
-tells me that it may not be too many people performing this particular action.
-The solution to the problem was found on \emph{Stack
+tells me that it may not be too many people performing this particular action.
+The solution to the problem was found on \name{Stack
Overflow}\footnote{\url{https://stackoverflow.com/questions/12401297}}. It
-contains enough dirty details to be considered unconvenient to use, if not
+contains enough dirty details to be considered inconvenient to use, if not
wrapping it in a class like my \type{ProjectImporter}. One would probably have
to delve into the source code for the import wizard to find out how the import
operation works, if no one had already done it.
\section{Statistics}
Statistics for the analysis and changes is captured by the
\typewithref{no.uio.ifi.refaktor.aspects}{StatisticsAspect}. This an
-\emph{aspect} written in \emph{AspectJ}.
+\emph{aspect} written in \name{AspectJ}.
\subsection{AspectJ}
-\emph{AspectJ}\footnote{\url{http://eclipse.org/aspectj/}} is an extension to
+\name{AspectJ}\footnote{\url{http://eclipse.org/aspectj/}} is an extension to
the Java language, and facilitates combining aspect-oriented programming with
the object-oriented programming in Java.
entangled with parts of the source code it does not really belong. Examples
include logging, debugging, optimization and security.
-Aspects is interacting with other modules by defining advices. An \emph{advice}
-in AspectJ is somewhat similar to a method in Java. It is meant to alter the
-behavior of other methods, and contains a body that is executed when it is
-applied.
+Aspects are interacting with other modules by defining advices. The concept of
+an \emph{advice} is known from both aspect-oriented and functional
+programming\citing{wikiAdvice2014}. It is a function that modifies another
+function when the latter is run. An advice in AspectJ is somewhat similar to a
+method in Java. It is meant to alter the behavior of other methods, and contains
+a body that is executed when it is applied.
An advice can be applied at a defined \emph{pointcut}. A pointcut picks out one
or more \emph{join points}. A join point is a well-defined point in the
\myref{lst:aspectjExample}.
\begin{listing}[h]
-\begin{minted}{java}
+\begin{minted}{aspectj}
pointcut methodAnalyze(
SearchBasedExtractAndMoveMethodAnalyzer analyzer) :
call(* SearchBasedExtractAndMoveMethodAnalyzer.analyze())
refactorings in isolation, as well as for the combination of them.
\section{Optimizations}
+When looking for optimizations to make for the benchmarking process, I used the
+\name{VisualVM}\footnote{\url{http://visualvm.java.net/}} \gloss{profiler} for
+the Java Virtual Machine to both profile the application and also to make memory
+dumps of its heap.
\subsection{Caching}
+When \gloss{profiling} the benchmark process before making any optimizations, it
+early became apparent that the parsing of source code was a place to direct
+attention towards. This discovery was done when only \emph{analyzing} source
+code, before trying to do any \emph{manipulation} of it. Caching of the parsed
+ASTs seemed like the best way to save some time, as expected. With only a simple
+cache of the most recently used AST, the analysis time was speeded up by a
+factor of around 20. This number depends a little upon which type of system the
+analysis is run.
+
+The caching is managed by a cache manager, that now, by default, utilizes the
+not so well known feature of Java called a \emph{soft reference}. Soft
+references are best explained in the context of weak references. A \emph{weak
+reference} is a reference to an object instance that is only guaranteed to
+persist as long as there is a \emph{strong reference} or a soft reference
+referring the same object. If no such reference is found, its referred object is
+garbage collected. A strong reference is basically the same as a regular Java
+reference. A soft reference has the same guarantees as a week reference when it
+comes to its relation to strong references, but it is not necessarily garbage
+collected whenever there exists no strong references to it. A soft reference
+\emph{may} reside in memory as long as the JVM has enough free memory in the
+heap. A soft reference will therefore usually perform better than a weak
+reference when used for simple caching and similar tasks. The way to use a
+soft/weak reference is to as it for its referent. The return value then has to
+be tested to check that it is not \var{null}. For the basic usage of soft
+references, see \myref{lst:softReferenceExample}. For a more thorough
+explanation of weak references in general, see\citing{weakRef2006}.
+
+\begin{listing}[h]
+\begin{minted}{java}
+// Strong reference
+Object strongRef = new Object();
+
+// Soft reference
+SoftReference<Object> softRef =
+ new SoftReference<Object>(new Object());
+
+// Using the soft reference
+Object obj = softRef.get();
+if (obj != null) {
+ // Use object here
+}
+\end{minted}
+\caption{Showing the basic usage of soft references. Weak references is used the
+ same way. {\footnotesize (The references are part of the \code{java.lang.ref}
+package.)}}
+\label{lst:softReferenceExample}
+\end{listing}
+
+The cache based on soft references has no limit for how many ASTs it caches. It
+is generally not advisable to keep references to ASTs for prolonged periods of
+time, since they are expensive structures to hold on to. For regular plugin
+development, \name{Eclipse} recommends not creating more than one AST at a time to
+limit memory consumption. Since the benchmarking has nothing to do with user
+experience, and throughput is everything, these advices are intentionally
+ignored. This means that during the benchmarking process, the target \name{Eclipse}
+application may very well work close to its memory limit for the heap space for
+long periods during the benchmark.
+
+\subsection{Candidates stored as mementos}
+When performing large scale analysis of source code for finding candidates to
+the \ExtractAndMoveMethod refactoring, memory is an issue. One of the inputs to
+the refactoring is a variable binding. This variable binding indirectly retains
+a whole AST. Since ASTs are large structures, this quickly leads to an
+\type{OutOfMemoryError} if trying to analyze a large project without optimizing
+how we store the candidates data. This means that the JVM cannot allocate more
+memory for out benchmark, and it exists disgracefully.
+
+A possible solution could be to just allow the JVM to allocate even more memory,
+but this is not a dependable solution. The allocated memory could easily
+supersede the physical memory of a machine, and that would make the benchmark go
+really slow.
+
+Thus, the candidates data must be stored in another format. Therefore, we use
+the \gloss{mementoPattern} to store the variable binding information. This is
+done in a way that makes it possible to retrieve the variable binding at a later
+point. The data that is stored to achieve this, is the key to the original
+variable binding. In addition to the key, we know which method and text
+selection the variable is referenced in, so that we can find it by parsing the
+source code and search for it when it is needed.
+
+\section{Handling failures}
+\todoin{write}
+
+
+\chapter{Technicalities}
+
+\section{Source code organization}
+All the parts of this master's project is under version control with
+\name{Git}\footnote{\url{http://git-scm.com/}}.
+
+The software written is organized as some \name{Eclipse} plugins. Writing a plugin is
+the natural way to utilize the API of \name{Eclipse}. This also makes it possible to
+provide a user interface to manually run operations on selections in program
+source code or whole projects/packages.
+
+When writing a plugin in \name{Eclipse}, one has access to resources such as the
+current workspace, the open editor and the current selection.
+
+The thesis work is contained in the following Eclipse projects:
+
+\begin{description}
+ \item[no.uio.ifi.refaktor] \hfill \\ This is the main Eclipse plugin
+ project, and contains all of the business logic for the plugin.
+
+ \item[no.uio.ifi.refaktor.tests] \hfill \\
+ This project contains the tests for the main plugin.
+
+ \item[no.uio.ifi.refaktor.examples] \hfill \\
+ Contains example code used in testing. It also contains code for managing
+ this example code, such as creating an Eclipse project from it before a test
+ run.
+
+ \item[no.uio.ifi.refaktor.benchmark] \hfill \\
+ This project contains code for running search based versions of the
+ composite refactoring over selected Eclipse projects.
+
+ \item[no.uio.ifi.refaktor.releng] \hfill \\
+ Contains the rmap, queries and target definitions needed by by Buckminster
+ on the Jenkins continuous integration server.
+
+\end{description}
+
+\subsection{The no.uio.ifi.refaktor project}
+
+\subsubsection{no.uio.ifi.refaktor.analyze}
+This package, and its sub-packages, contains code that is used for analyzing
+Java source code. The most important sub-packages are presented below.
+
+\begin{description}
+ \item[no.uio.ifi.refaktor.analyze.analyzers] \hfill \\
+ This package contains source code analyzers. These are usually responsible
+ for analyzing text selections or running specialized analyzers for different
+ kinds of entities. Their structure are often hierarchical. This means that
+ you have an analyzer for text selections, that in turn is utilized by an
+ analyzer that analyzes all the selections of a method. Then there are
+ analyzers for analyzing all the methods of a type, all the types of a
+ compilation unit, all the compilation units of a package, and, at last, all
+ of the packages in a project.
+
+ \item[no.uio.ifi.refaktor.analyze.checkers] \hfill \\
+ A package containing checkers. The checkers are classes used to validate
+ that a selection can be further analyzed and chosen as a candidate for a
+ refactoring. Invalidating properties can be such as usage of inner classes
+ or the need for multiple return values.
+
+ \item[no.uio.ifi.refaktor.analyze.collectors] \hfill \\
+ This package contains the property collectors. Collectors are used to gather
+ properties from a text selection. This is mostly properties regarding
+ referenced names and their occurrences. It is these properties that makes up
+ the basis for finding the best candidates for a refactoring.
+\end{description}
+
+\subsubsection{no.uio.ifi.refaktor.change}
+This package, and its sub-packages, contains functionality for manipulate source
+code.
+
+\begin{description}
+ \item[no.uio.ifi.refaktor.change.changers] \hfill \\
+ This package contains source code changers. They are used to glue together
+ the analysis of source code and the actual execution of the changes.
+
+ \item[no.uio.ifi.refaktor.change.executors] \hfill \\
+ The executors that are responsible for making concrete changes are found in
+ this package. They are mostly used to create and execute one or more Eclipse
+ refactorings.
+
+ \item[no.uio.ifi.refaktor.change.processors] \hfill \\
+ Contains a refactoring processor for the \MoveMethod refactoring. The code
+ is stolen and modified to fix a bug. The related bug is described in
+ \myref{eclipse_bug_429416}.
+
+\end{description}
+
+\subsubsection{no.uio.ifi.refaktor.handlers}
+This package contains handlers for the commands defined in the plugin manifest.
+
+\subsubsection{no.uio.ifi.refaktor.prefix}
+This package contains the \type{Prefix} type that is the data representation of
+the prefixes found by the \type{PrefixesCollector}. It also contains the prefix
+set for storing and working with prefixes.
+
+\subsubsection{no.uio.ifi.refaktor.statistics}
+The package contains statistics functionality. Its heart is the statistics
+aspect that is responsible for gathering statistics during the execution of the
+\ExtractAndMoveMethod refactoring.
+
+\begin{description}
+ \item[no.uio.ifi.refaktor.statistics.reports] \hfill \\
+ This package contains a simple framework for generating reports from the
+ statistics data generated by the aspect. Currently, the only available
+ report type is a simple text report.
+
+\end{description}
+
+
+\subsubsection{no.uio.ifi.refaktor.textselection}
+This package contains the two custom text selections that are used extensively
+throughout the project. One of them is just a subclass of the other, to support
+the use of the memento pattern to optimize the memory usage during benchmarking.
+
+\subsubsection{no.uio.ifi.refaktor.debugging}
+The package contains a debug utility class. I addition to this, the package
+\code{no.uio.ifi.refaktor.utils.aspects} contains a couple of aspects used for
+debugging purposes.
+
+\subsubsection{no.uio.ifi.refaktor.utils}
+Utility package that contains all the functionality that has to do with parsing
+of source code. It also has utility classes for looking up handles to methods
+and types et cetera.
+
+\begin{description}
+ \item[no.uio.ifi.refaktor.utils.caching] \hfill \\
+ This package contains the caching manager for compilation units, along with
+ classes for different caching strategies.
+
+ \item[no.uio.ifi.refaktor.utils.nullobjects] \hfill \\
+ Contains classes for creating different null objects. Most of the classes is
+ used to represent null objects of different handle types. These null objects
+ are returned from various utility classes instead of returning a \var{null}
+ value when other values are not available.
+
+\end{description}
+
+\section{Continuous integration}
+The continuous integration server
+\name{Jenkins}\footnote{\url{http://jenkins-ci.org/}} has been set up for the
+project\footnote{A work mostly done by the supervisor.}. It is used as a way to
+run tests and perform code coverage analysis.
+
+To be able to build the \name{Eclipse} plugins and run tests for them with Jenkins, the
+component assembly project
+\name{Buckminster}\footnote{\url{http://www.eclipse.org/buckminster/}} is used,
+through its plugin for Jenkins. Buckminster provides for a way to specify the
+resources needed for building a project and where and how to find them.
+Buckminster also handles the setup of a target environment to run the tests in.
+All this is needed because the code to build depends on an \name{Eclipse}
+installation with various plugins.
+
+\subsection{Problems with AspectJ}
+The Buckminster build worked fine until introducing AspectJ into the project.
+When building projects using AspectJ, there are some additional steps that needs
+to be performed. First of all, the aspects themselves must be compiled. Then the
+aspects needs to be woven with the classes they affect. This demands a process
+that does multiple passes over the source code.
+
+When using AspectJ with \name{Eclipse}, the specialized compilation and the
+weaving can be handled by the \name{AspectJ Development
+Tools}\footnote{\url{https://www.eclipse.org/ajdt/}}. This works all fine, but
+it complicates things when trying to build a project depending on \name{Eclipse}
+plugins outside of \name{Eclipse}. There is supposed to be a way to specify a
+compiler adapter for javac, together with the file extensions for the file types
+it shall operate. The AspectJ compiler adapter is called
+\typewithref{org.aspectj.tools.ant.taskdefs}{Ajc11CompilerAdapter}, and it works
+with files that has the extensions \code{*.java} and \code{*.aj}. I tried to
+setup this in the build properties file for the project containing the aspects,
+but to no avail. The project containing the aspects does not seem to be built at
+all, and the projects that depends on it complains that they cannot find certain
+classes.
+
+I then managed to write an \name{Ant}\footnote{\url{https://ant.apache.org/}}
+build file that utilizes the AspectJ compiler adapter, for the
+\code{no.uio.ifi.refaktor} plugin. The problem was then that it could no longer
+take advantage of the environment set up by Buckminster. The solution to this
+particular problem was of a ``hacky'' nature. It involves exporting the plugin
+dependencies for the project to an Ant build file, and copy the exported path
+into the existing build script. But then the Ant script needs to know where the
+local \name{Eclipse} installation is located. This is no problem when building
+on a local machine, but to utilize the setup done by Buckminster is a problem
+still unsolved. To get the classpath for the build setup correctly, and here
+comes the most ``hacky'' part of the solution, the Ant script has a target for
+copying the classpath elements into a directory relative to the project
+directory and checking it into Git. When no \code{ECLIPSE\_HOME} property is set
+while running Ant, the script uses the copied plugins instead of the ones
+provided by the \name{Eclipse} installation when building the project. This
+obviously creates some problems with maintaining the list of dependencies in the
+Ant file, as well as remembering to copy the plugins every time the list of
+dependencies change.
+
+The Ant script described above is run by Jenkins before the Buckminster setup
+and build. When setup like this, the Buckminster build succeeds for the projects
+not using AspectJ, and the tests are run as normal. This is all good, but it
+feels a little scary, since the reason for Buckminster not working with AspectJ
+is still unknown.
+
+The problems with building with AspectJ on the Jenkins server lasted for a
+while, before they were solved. This is reflected in the ``Test Result Trend''
+and ``Code Coverage Trend'' reported by Jenkins.
+
+
+
+\chapter{Conclusions and Future Work}
+\todoin{Write}
+
+\section{Future work}
+
+
+\appendix
-\subsection{Memento}
\chapter{Eclipse Bugs Found}
-\todoin{Add other things and change headline?}
+\newcommand{\submittedBugReport}[1]{The submitted bug report can be found on
+ \url{#1}.}
\section{Eclipse bug 420726: Code is broken when moving a method that is
assigning to the parameter that is also the move
destination}\label{eclipse_bug_420726}
-This bug\footnote{\url{https://bugs.eclipse.org/bugs/show\_bug.cgi?id=420726}}
+This bug
was found when analyzing what kinds of names that was to be considered as
\emph{unfixes} \see{unfixes}.
\subsection{The bug}
The bug emerges when trying to move a method from one class to another, and when
the target for the move (must be a variable, local or field) is both a parameter
-variable and also is assigned to within the method body. Eclipse allows this to
+variable and also is assigned to within the method body. \name{Eclipse} allows this to
happen, although it is the sure path to a compilation error. This is because we
would then have an assignment to a \var{this} expression, which is not allowed
-in Java.
+in Java.
+\submittedBugReport{https://bugs.eclipse.org/bugs/show\_bug.cgi?id=420726}
\subsection{The solution}
The solution to this problem is to add all simple names that are assigned to in
a method body to the set of unfixes.
-\section{Eclipse bug 429416: IAE when moving method from anonymous class}
-I
-discovered\footnote{\url{https://bugs.eclipse.org/bugs/show\_bug.cgi?id=429416}}
+\section{Eclipse bug 429416: IAE when moving method from anonymous
+class}\label{eclipse_bug_429416}
+I discovered
this bug during a batch change on the \type{org.eclipse.jdt.ui} project.
\subsection{The bug}
-This bug surfaces when trying to use the Move Method refactoring to move a
+This bug surfaces when trying to use the \refa{Move Method} refactoring to move a
method from an anonymous class to another class. This happens both for my
-simulation as well as in Eclipse, through the user interface. It only occurs
-when Eclipse analyzes the program and finds it necessary to pass an instance of
+simulation as well as in \name{Eclipse}, through the user interface. It only occurs
+when \name{Eclipse} analyzes the program and finds it necessary to pass an instance of
the originating class as a parameter to the moved method. I.e. it want to pass a
\var{this} expression. The execution ends in an
\typewithref{java.lang}{IllegalArgumentException} in
invocation where the previous invocation to the method that was moved was. From
its code it can be read that when a \var{this} expression is going to be passed
in to the invocation, it shall be qualified with the name of the original
-method's declaring class, if the declaring class is either an anonymous clas or
+method's declaring class, if the declaring class is either an anonymous class or
a member class. The problem with this, is that an anonymous class does not have
a name, hence the term \emph{anonymous} class! Therefore, when its name, an
empty string, is passed into
\methodwithref{org.eclipse.jdt.core.dom.AST}{newSimpleName} it all ends in an
-\type{IllegalArgumentException}.
+\type{IllegalArgumentException}.
+\submittedBugReport{https://bugs.eclipse.org/bugs/show\_bug.cgi?id=429416}
\subsection{How I solved the problem}
Since the \type{MoveInstanceMethodProcessor} is instantiated in the
\typewithref{org.eclipse.ltk.core.refactoring.participants}{MoveProcessor}, I
was able to copy the code for the original move processor and modify it so that
it works better for me. It is now called
-\typewithref{no.uio.ifi.refaktor.refactorings.processors}{ModifiedMoveInstanceMethodProcessor}.
+\typewithref{no.uio.ifi.refaktor.change.processors}{ModifiedMoveInstanceMethodProcessor}.
The only modification done (in addition to some imports and suppression of
warnings), is in the \method{createInlinedMethodInvocation}. When the declaring
class of the method to move is anonymous, the \var{this} expression in the
\section{Eclipse bug 429954: Extracting statement with reference to local type
breaks code}\label{eclipse_bug_429954}
-The bug\footnote{\url{https://bugs.eclipse.org/bugs/show\_bug.cgi?id=429954}}
+The bug
was discovered when doing some changes to the way unfixes is computed.
\subsection{The bug}
-The problem is that Eclipse is allowing selections that references variables of
+The problem is that \name{Eclipse} is allowing selections that references variables of
local types to be extracted. When this happens the code is broken, since the
extracted method must take a parameter of a local type that is not in the
methods scope. The problem is illustrated in
-\myref{lst:extractMethod_LocalClass}, but there in another setting.
+\myref{lst:extractMethod_LocalClass}, but there in another setting.
+\submittedBugReport{https://bugs.eclipse.org/bugs/show\_bug.cgi?id=429954}
\subsection{Actions taken}
There are no actions directly springing out of this bug, since the Extract
Method refactoring cannot be meant to be this way. This is handled on the
-analysis stage of our Extract and Move Method refactoring. So names representing
+analysis stage of our \refa{Extract and Move Method} refactoring. So names representing
variables of local types is considered unfixes \see{unfixes}.
\todoin{write more when fixing this in legal statements checker}
-
-\chapter{Related Work}
-
-\section{The compositional paradigm of refactoring}
-This paradigm builds upon the observation of Vakilian et
-al.\citing{vakilian2012}, that of the many automated refactorings existing in
-modern IDEs, the simplest ones are dominating the usage statistics. The report
-mainly focuses on \emph{Eclipse} as the tool under investigation.
-
-The paradigm is described almost as the opposite of automated composition of
-refactorings \see{compositeRefactorings}. It works by providing the programmer
-with easily accessible primitive refactorings. These refactorings shall be
-accessed via keyboard shortcuts or quick-assist menus\footnote{Think
-quick-assist with Ctrl+1 in Eclipse} and be promptly executed, opposed to in the
-currently dominating wizard-based refactoring paradigm. They are ment to
-stimulate composing smaller refactorings into more complex changes, rather than
-doing a large upfront configuration of a wizard-based refactoring, before
-previewing and executing it. The compositional paradigm of refactoring is
-supposed to give control back to the programmer, by supporting \himher with an
-option of performing small rapid changes instead of large changes with a lesser
-degree of control. The report authors hope this will lead to fewer unsuccessful
-refactorings. It also could lower the bar for understanding the steps of a
-larger composite refactoring and thus also help in figuring out what goes wrong
-if one should choose to op in on a wizard-based refactoring.
-
-Vakilian and his associates have performed a survey of the effectiveness of the
-compositional paradigm versus the wizard-based one. They claim to have found
-evidence of that the \emph{compositional paradigm} outperforms the
-\emph{wizard-based}. It does so by reducing automation, which seem
-counterintuitive. Therefore they ask the question ``What is an appropriate level
-of automation?'', and thus questions what they feel is a rush toward more
-automation in the software engineering community.
-
-
\backmatter{}
+\printglossaries
\printbibliography
\listoftodos
\end{document}
git://git.uio.no / ifi-stolz-refaktor.git / blobdiff