1 \documentclass[USenglish,11pt]{ifimaster}
3 \usepackage[utf8]{inputenc}
4 \usepackage[T1]{fontenc,url}
5 \usepackage{lmodern} % using Latin Modern to be able to use bold typewriter font
12 \usepackage{tikz-qtree}
13 \usetikzlibrary{shapes,snakes,trees,arrows,shadows,positioning,calc}
14 \usepackage{babel,textcomp,csquotes,ifimasterforside}
17 \usepackage[hidelinks]{hyperref}
19 \usepackage[xindy]{glossaries}
21 \usepackage[style=alphabetic,backend=biber,doi=false,isbn=false]{biblatex}
23 \usepackage{mathtools}
25 % use 'disable' before printing:
26 \usepackage[]{todonotes}
34 \def\mintedframesep{11pt}
36 \usepackage{perpage} %the perpage package
37 \MakePerPage{footnote} %the perpage package command
39 \theoremstyle{definition}
40 \newtheorem*{wordDef}{Definition}
41 \newtheorem*{theorem}{Theorem}
43 \graphicspath{ {./figures/} }
45 \newcommand{\citing}[1]{~\cite{#1}}
47 \newcommand{\myref}[1]{\vref{#1}}
48 \newcommand{\Myref}[1]{\Vref{#1}}
49 %\newcommand{\myref}[1]{\ref{#1}}
50 %\newcommand{\Myref}[1]{\ref{#1}}
51 \newcommand{\mysimpleref}[1]{\cref{#1}}
52 \newcommand{\Mysimpleref}[1]{\Cref{#1}}
54 %\newcommand{\glossref}[1]{\textsuperscript{(\glsrefentry{#1})}}
55 %\newcommand{\gloss}[1]{\gls{#1}\glossref{#1}}
56 %\newcommand{\glosspl}[1]{\glspl{#1}\glossref{#1}}
57 \newcommand{\gloss}[1]{\gls{#1}}
58 \newcommand{\glosspl}[1]{\glspl{#1}}
60 \newcommand{\definition}[1]{\begin{wordDef}#1\end{wordDef}}
61 \newcommand{\see}[1]{(see \myref{#1})}
62 \newcommand{\explanation}[3]{\noindent\textbf{\textit{#1}}\\*\emph{When:}
63 #2\\*\emph{How:} #3\\*[-7px]}
65 %\newcommand{\type}[1]{\lstinline{#1}}
66 \newcommand{\code}[1]{\texttt{\textbf{#1}}}
67 \newcommand{\type}[1]{\code{#1}}
68 \newcommand{\typeref}[1]{\footnote{\type{#1}}}
69 \newcommand{\typewithref}[2]{\type{#2}\typeref{#1.#2}}
70 \newcommand{\method}[1]{\type{#1}}
71 \newcommand{\methodref}[2]{\footnote{\type{#1}\method{\##2()}}}
72 \newcommand{\methodwithref}[2]{\method{#2}\footnote{\type{#1}\method{\##2()}}}
73 \newcommand{\var}[1]{\type{#1}}
75 \newcommand{\name}[1]{#1}
76 \newcommand{\tit}[1]{\emph{#1}}
77 \newcommand{\refa}[1]{\emph{#1}}
78 \newcommand{\pattern}[1]{\emph{#1}}
79 \newcommand{\metr}[1]{\emph{#1}}
80 \newcommand{\ExtractMethod}{\refa{Extract Method}\xspace}
81 \newcommand{\MoveMethod}{\refa{Move Method}\xspace}
82 \newcommand{\ExtractAndMoveMethod}{\refa{Extract and Move Method}\xspace}
84 \newcommand{\m}[1]{$#1$}
86 \newcommand\todoin[2][]{\todo[inline, caption={#2}, #1]{
87 \begin{minipage}{\textwidth-4pt}#2\end{minipage}}}
89 \title{Automated Composition of Refactorings}
90 \subtitle{Implementing and evaluating a search-based Extract and Move Method
92 \author{Erlend Kristiansen}
95 \newglossaryentry{profiling}
98 description={is to run a computer program through a profiler/with a profiler
101 \newglossaryentry{profiler}
104 description={A profiler is a program for analyzing performance within an
105 application. It is used to analyze memory consumption, processing time and
106 frequency of procedure calls and such}
108 \newglossaryentry{xUnit}
110 name={xUnit framework},
111 description={An xUnit framework is a framework for writing unit tests for a
112 computer program. It follows the patterns known from the JUnit framework for
113 Java\citing{fowlerXunit}
115 plural={xUnit frameworks}
117 \newglossaryentry{softwareObfuscation}
119 name={software obfuscation},
120 description={makes source code harder to read and analyze, while preserving
123 \newglossaryentry{extractClass}
125 name=\refa{Extract Class},
126 description={The \refa{Extract Class} refactoring works by creating a class,
127 for then to move members from another class to that class and access them from
128 the old class via a reference to the new class}
130 \newglossaryentry{designPattern}
132 name={design pattern},
133 description={A design pattern is a named abstraction that is meant to solve a
134 general design problem. It describes the key aspects of a common problem and
135 identifies its participators and how they collaborate},
136 plural={design patterns}
138 \newglossaryentry{enclosingClass}
140 name={enclosing class},
141 description={An enclosing class is the class that surrounds any specific piece
142 of code that is written in the inner scope of this class},
144 \newglossaryentry{mementoPattern}
146 name={memento pattern},
147 description={The memento pattern is a software design pattern that is used to
148 capture an object's internal state so that it can be restored to this state
149 later\citing{designPatterns}},
151 %\newglossaryentry{extractMethod}
153 % name=\refa{Extract Method},
154 % description={The \refa{Extract Method} refactoring is used to extract a
155 %fragment of code from its context and into a new method. A call to the new
156 %method is inlined where the fragment was before. It is used to break code into
157 %logical units, with names that explain their purpose}
159 %\newglossaryentry{moveMethod}
161 % name=\refa{Move Method},
162 % description={The \refa{Move Method} refactoring is used to move a method from
163 % one class to another. This is useful if the method is using more features of
164 % another class than of the class which it is currently defined. Then all calls
165 % to this method must be updated, or the method must be copied, with the old
166 %method delegating to the new method}
169 \bibliography{bibliography/master-thesis-erlenkr-bibliography}
170 \DefineBibliographyStrings{english}{%
171 bibliography = {References},
173 \newbibmacro{string+doi}[1]{%
174 \iffieldundef{doi}{#1}{\href{http://dx.doi.org/\thefield{doi}}{#1}}}
175 \DeclareFieldFormat{title}{\usebibmacro{string+doi}{\mkbibemph{#1}}}
176 \DeclareFieldFormat[article]{title}{\usebibmacro{string+doi}{\mkbibquote{#1}}}
178 % UML comment in TikZ:
179 % ref: https://tex.stackexchange.com/questions/103688/folded-paper-shape-tikz
181 \pgfdeclareshape{umlcomment}{
182 \inheritsavedanchors[from=rectangle] % this is nearly a rectangle
183 \inheritanchorborder[from=rectangle]
184 \inheritanchor[from=rectangle]{center}
185 \inheritanchor[from=rectangle]{north}
186 \inheritanchor[from=rectangle]{south}
187 \inheritanchor[from=rectangle]{west}
188 \inheritanchor[from=rectangle]{east}
189 % ... and possibly more
190 \backgroundpath{% this is new
191 % store lower right in xa/ya and upper right in xb/yb
192 \southwest \pgf@xa=\pgf@x \pgf@ya=\pgf@y
193 \northeast \pgf@xb=\pgf@x \pgf@yb=\pgf@y
194 % compute corner of ‘‘flipped page’’
195 \pgf@xc=\pgf@xb \advance\pgf@xc by-10pt % this should be a parameter
196 \pgf@yc=\pgf@yb \advance\pgf@yc by-10pt
197 % construct main path
198 \pgfpathmoveto{\pgfpoint{\pgf@xa}{\pgf@ya}}
199 \pgfpathlineto{\pgfpoint{\pgf@xa}{\pgf@yb}}
200 \pgfpathlineto{\pgfpoint{\pgf@xc}{\pgf@yb}}
201 \pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@yc}}
202 \pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@ya}}
205 \pgfpathmoveto{\pgfpoint{\pgf@xc}{\pgf@yb}}
206 \pgfpathlineto{\pgfpoint{\pgf@xc}{\pgf@yc}}
207 \pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@yc}}
208 \pgfpathlineto{\pgfpoint{\pgf@xc}{\pgf@yc}}
213 \tikzstyle{comment}=[%
226 %\interfootnotelinepenalty=10000
228 % Space between table rows
229 \renewcommand{\arraystretch}{1.3}
231 \newcommand{\spancols}[2]{\multicolumn{#1}{@{}l@{}}{#2}}
233 \newcolumntype{L}[1]{>{\hsize=#1\hsize\raggedright\arraybackslash}X}%
234 \newcolumntype{R}[1]{>{\hsize=#1\hsize\raggedleft\arraybackslash}X}%
236 \setcounter{tocdepth}{1}
239 %\pagenumbering{arabic}
244 %\setcounter{page}{3}
247 Complex source code impacts the cost of software maintenance in a negative way.
248 In an object-oriented context, one class may depend on a high number of other
249 classes, thus contributing to the complexity of a program and making changing
250 code prone to errors. Refactoring is a means to fight such complexity.
252 This thesis investigates whether automated refactoring can be used to lower the
253 coupling between classes. A search-based composite refactoring combining the
254 primitive refactorings \ExtractMethod and \MoveMethod is designed as a possible
255 solution to this problem. Case studies are conducted to evaluate the effect of
256 executing the search-based refactoring in a large code base.
260 The results from the case studies indicate that the refactoring has the
261 potential of lowering coupling, but that the analysis performed before
262 refactoring is not complete enough. This results in a large number of errors
263 caused by the refactoring. The refactoring has not been properly evaluated for
264 behavior changes. A complete pre-refactoring analysis for the search-based
265 refactoring is still an open problem.
267 The efficiency and unreliability of the search-based refactoring makes it
268 unsuitable for on-demand large-scale refactoring tasks. With some modifications,
269 and extensive improvements, the work done for this thesis could be used to
270 develop a tool for performing long-running analysis, which can be used to
271 suggest code improvements.
275 \todoin{\textbf{Remove all todos (including list) before delivery/printing!!!
276 Can be done by removing ``draft'' from documentclass.}}
277 \todoin{Fix cross-references}
284 \chapter*{Acknowledgements}
288 %\setcounter{page}{13}
290 \chapter{Introduction}
292 \section{Motivation and structure}
294 For large software projects, complex program source code is an issue. It
295 impacts the cost of maintenance in a negative
296 way\citing{bankerMaintenanceCost1993}, and often stalls the implementation of
297 new functionality and other program changes. The code may be difficult to
298 understand, the changes may introduce new bugs that are hard to find and its
299 complexity can simply keep people from doing code changes, in fear of breaking
300 some dependent piece of code. All these problems are related, and often lead to
301 a vicious circle that slowly degrades the overall quality of a project.
303 More specifically, and in an object-oriented context, a class may depend on a
304 number of other classes. Sometimes these intimate relationships are appropriate,
305 and sometimes they are not. Inappropriate \emph{coupling} between classes can
306 make it difficult to know whether or not a change that is aimed at fixing a
307 specific problem also alters the behavior of another part of a program.
309 One of the tools that are used to fight complexity and coupling in program
310 source code is \emph{refactoring}. The intention for this master's thesis is
311 therefore to create an automated composite refactoring that reduces coupling
312 between classes. The refactoring shall be able to operate automatically in all
313 phases of a refactoring, from performing analysis to executing changes. It is
314 also a requirement that it should be able to process large quantities of source
315 code in a reasonable amount of time.
317 The current chapter proceeds in \mysimpleref{sec:refactoring} by describing what
318 refactoring is. Then the project is presented in \mysimpleref{sec:project},
319 before the chapter is concluded with a brief discussion of related work in
320 \mysimpleref{sec:relatedWork}.
322 \Mysimpleref{ch:extractAndMoveMethod} shows the workings of our refactoring
323 together with an example illustrating how it works for a specific case.
324 \Mysimpleref{ch:eclipse} presents some of the APIs and frameworks that are
325 relevant for source code analysis and change, and that are available when using
326 the Eclipse Platform with the Java development tools installed.
327 \Mysimpleref{ch:implementation} contains some implementation details
328 of what was presented in \mysimpleref{ch:extractAndMoveMethod}.
329 \Mysimpleref{ch:caseStudies} presents a couple of case studies used to evaluate
330 several aspects of our refactoring. The whole thesis is then winded up in
331 \mysimpleref{ch:conclusions} with conclusions and future work.
334 \section{What is refactoring?}\label{sec:refactoring}
336 This question is best answered by first defining the concept of a
337 \emph{refactoring}, what it is to \emph{refactor}, and then discuss what aspects
338 of programming make people want to refactor their code.
340 \subsection{Defining refactoring}
341 Martin Fowler, in his classic book on refactoring\citing{refactoring}, defines a
342 refactoring like this:
345 \emph{Refactoring} (noun): a change made to the internal
346 structure\footnote{The structure observable by the programmer.} of software to
347 make it easier to understand and cheaper to modify without changing its
348 observable behavior.~\cite[p.~53]{refactoring}
351 \noindent This definition assigns additional meaning to the word
352 \emph{refactoring}, beyond the composition of the prefix \emph{re-}, usually
353 meaning something like ``again'' or ``anew'', and the word \emph{factoring},
354 which can mean to isolate the \emph{factors} of something. Here a \emph{factor}
355 would be close to the mathematical definition of something that divides a
356 quantity, without leaving a remainder. Fowler is mixing the \emph{motivation}
357 behind refactoring into his definition. Instead it could be more refined, formed
358 to only consider the \emph{mechanical} and \emph{behavioral} aspects of
359 refactoring. That is to factor the program again, putting it together in a
360 different way than before, while preserving the behavior of the program. An
361 alternative definition could then be:
363 \definition{A \emph{refactoring} is a transformation
364 done to a program without altering its external behavior.}
366 From this we can conclude that a refactoring primarily changes how the
367 \emph{code} of a program is perceived by the \emph{programmer}, and not the
368 \emph{behavior} experienced by any user of the program. Although the logical
369 meaning is preserved, such changes could potentially alter the program's
370 behavior when it comes to performance gain or -penalties. So any logic depending
371 on the performance of a program could make the program behave differently after
374 In the extreme case one could argue that \gloss{softwareObfuscation} is
375 refactoring. It is often used to protect proprietary software. It restrains
376 uninvited viewers, so they have a hard time analyzing code that they are not
377 supposed to know how works. This could be a problem when using a language that
378 is possible to decompile, such as Java.
380 Obfuscation could be done composing many, more or less randomly chosen,
381 refactorings. Then the question arises whether it can be called a
382 \emph{composite refactoring} or not \see{compositeRefactorings}? The answer is
383 not obvious. First, there is no way to describe the mechanics of software
384 obfuscation, because there are infinitely many ways to do that. Second,
385 obfuscation can be thought of as \emph{one operation}: Either the code is
386 obfuscated, or it is not. Third, it makes no sense to call software obfuscation
387 \emph{a refactoring}, since it holds different meaning to different people.
389 This last point is important, since one of the motivations behind defining
390 different refactorings, is to establish a \emph{vocabulary} for software
391 professionals to use when reasoning about and discussing programs, similar to
392 the motivation behind \glosspl{designPattern}\citing{designPatterns}.
394 So for describing \emph{software obfuscation}, it might be more appropriate to
395 define what you do when performing it rather than precisely defining its
396 mechanics in terms of other refactorings.
399 \subsection{The etymology of 'refactoring'}
400 It is a little difficult to pinpoint the exact origin of the word
401 ``refactoring'', as it seems to have evolved as part of a colloquial
402 terminology, more than a scientific term. There is no authoritative source for a
403 formal definition of it.
405 According to Martin Fowler\citing{etymology-refactoring}, there may also be more
406 than one origin of the word. The most well-known source, when it comes to the
407 origin of \emph{refactoring}, is the
408 Smalltalk\footnote{\label{footNote}Programming language} community and their
409 infamous \name{Refactoring
410 Browser}\footnote{\url{http://st-www.cs.illinois.edu/users/brant/Refactory/RefactoringBrowser.html}}
411 described in the article \tit{A Refactoring Tool for
412 Smalltalk}\citing{refactoringBrowser1997}, published in 1997.
413 Allegedly\citing{etymology-refactoring}, the metaphor of factoring programs was
414 also present in the Forth\textsuperscript{\ref{footNote}} community, and the
415 word ``refactoring'' is mentioned in a book by Leo Brodie, called \tit{Thinking
416 Forth}\citing{brodie2004}, first published in 1984\footnote{\tit{Thinking Forth}
417 was first published in 1984 by the \name{Forth Interest Group}. Then it was
418 reprinted in 1994 with minor typographical corrections, before it was
419 transcribed into an electronic edition typeset in \LaTeX\ and published under a
420 Creative Commons license in
421 2004. The edition cited here is the 2004 edition, but the content should
422 essentially be as in 1984.}. The exact word is only printed one
423 place~\cite[p.~232]{brodie2004}, but the term \emph{factoring} is prominent in
424 the book, which also contains a whole chapter dedicated to (re)factoring, and
425 how to keep the (Forth) code clean and maintainable.
428 \ldots good factoring technique is perhaps the most important skill for a
429 Forth programmer.~\cite[p.~172]{brodie2004}
432 \noindent Brodie also express what \emph{factoring} means to him:
435 Factoring means organizing code into useful fragments. To make a fragment
436 useful, you often must separate reusable parts from non-reusable parts. The
437 reusable parts become new definitions. The non-reusable parts become arguments
438 or parameters to the definitions.~\cite[p.~172]{brodie2004}
441 Fowler claims that the usage of the word \emph{refactoring} did not pass between
442 the \name{Forth} and \name{Smalltalk} communities, but that it emerged
443 independently in each of the communities.
445 \subsection{Reasons for refactoring}
446 There are many reasons why people want to refactor their programs. They can for
447 instance do it to remove duplication, break up long methods or to introduce
448 design patterns into their software systems. The shared trait for all these is
449 that peoples' intentions are to make their programs \emph{better}, in some
450 sense. But what aspects of their programs are becoming improved?
452 As just mentioned, people often refactor to get rid of duplication. They are
453 moving identical or similar code into methods, and are pushing methods up or
454 down in their class hierarchies. They are making template methods for
455 overlapping algorithms/functionality, and so on. It is all about gathering what
456 belongs together and putting it all in one place. The resulting code is then
457 easier to maintain. When removing the implicit coupling\footnote{When
458 duplicating code, the duplicate pieces of code might not be coupled, apart
459 from representing the same functionality. So if this functionality is going to
460 change, it might need to change in more than one place, thus creating an
461 implicit coupling between multiple pieces of code.} between code snippets, the
462 location of a bug is limited to only one place, and new functionality need only
463 to be added to this one place, instead of a number of places people might not
466 A problem you often encounter when programming, is that a program contains a lot
467 of long and hard-to-grasp methods. It can then help to break the methods into
468 smaller ones, using the \ExtractMethod refactoring\citing{refactoring}. Then
469 you may discover something about a program that you were not aware of before;
470 revealing bugs you did not know about or could not find due to the complex
471 structure of your program. Making the methods smaller and giving good names to
472 the new ones clarifies the algorithms and enhances the \emph{understandability}
473 of the program \see{magic_number_seven}. This makes refactoring an excellent
474 method for exploring unknown program code, or code that you had forgotten that
477 Most primitive refactorings are simple, and usually involves moving code
478 around\citing{kerievsky2005}. The motivation behind them may first be revealed
479 when they are combined into larger --- higher level --- refactorings, called
480 \emph{composite refactorings} \see{compositeRefactorings}. Often the goal of
481 such a series of refactorings is a design pattern. Thus the design can
482 \emph{evolve} throughout the lifetime of a program, as opposed to designing
483 up-front. It is all about being structured and taking small steps to improve a
486 Many software design pattern are aimed at lowering the coupling between
487 different classes and different layers of logic. One of the most famous is
488 perhaps the \pattern{Model-View-Controller}\citing{designPatterns} pattern. It
489 is aimed at lowering the coupling between the user interface, the business logic
490 and the data representation of a program. This also has the added benefit that
491 the business logic could much easier be the target of automated tests, thus
492 increasing the productivity in the software development process.
494 Another effect of refactoring is that with the increased separation of concerns
495 coming out of many refactorings, the \emph{performance} can be improved. When
496 profiling programs, the problematic parts are narrowed down to smaller parts of
497 the code, which are easier to tune, and optimization can be performed only where
498 needed and in a more effective way\citing{refactoring}.
500 Last, but not least, and this should probably be the best reason to refactor, is
501 to refactor to \emph{facilitate a program change}. If one has managed to keep
502 one's code clean and tidy, and the code is not bloated with design patterns that
503 are not ever going to be needed, then some refactoring might be needed to
504 introduce a design pattern that is appropriate for the change that is going to
507 Refactoring program code --- with a goal in mind --- can give the code itself
508 more value. That is in the form of robustness to bugs, understandability and
509 maintainability. Having robust code is an obvious advantage, but
510 understandability and maintainability are both very important aspects of
511 software development. By incorporating refactoring in the development process,
512 bugs are found faster, new functionality is added more easily and code is easier
513 to understand by the next person exposed to it, which might as well be the
514 person who wrote it. The consequence of this, is that refactoring can increase
515 the average productivity of the development process, and thus also add to the
516 monetary value of a business in the long run. The perspective on productivity
517 and money should also be able to open the eyes of the many nearsighted managers
518 that seldom see beyond the next milestone.
520 \subsection{The magical number seven}\label{magic_number_seven}
521 The article \tit{The magical number seven, plus or minus two: some limits on our
522 capacity for processing information}\citing{miller1956} by George A. Miller,
523 was published in the journal \name{Psychological Review} in 1956. It presents
524 evidence that support that the capacity of the number of objects a human being
525 can hold in its working memory is roughly seven, plus or minus two objects. This
526 number varies a bit depending on the nature and complexity of the objects, but
527 is according to Miller ``\ldots never changing so much as to be
530 Miller's article culminates in the section called \emph{Recoding}, a term he
531 borrows from communication theory. The central result in this section is that by
532 recoding information, the capacity of the amount of information that a human can
533 process at a time is increased. By \emph{recoding}, Miller means to group
534 objects together in chunks, and give each chunk a new name that it can be
538 \ldots recoding is an extremely powerful weapon for increasing the amount of
539 information that we can deal with.~\cite[p.~95]{miller1956}
542 By organizing objects into patterns of ever growing depth, one can memorize and
543 process a much larger amount of data than if it were to be represented as its
544 basic pieces. This grouping and renaming is analogous to how many refactorings
545 work, by grouping pieces of code and give them a new name. Examples are the
546 fundamental \ExtractMethod and \refa{Extract Class}
547 refactorings\citing{refactoring}.
549 An example from the article addresses the problem of memorizing a sequence of
550 binary digits. The example presented here is a slightly modified version of the
551 one presented in the original article\citing{miller1956}, but it preserves the
552 essence of it. Let us say we have the following sequence of
553 16 binary digits: ``1010001001110011''. Most of us will have a hard time
554 memorizing this sequence by only reading it once or twice. Imagine if we instead
555 translate it to this sequence: ``A273''. If you have a background from computer
556 science, it will be obvious that the latter sequence is the first sequence
557 recoded to be represented by digits in base 16. Most people should be able to
558 memorize this last sequence by only looking at it once.
560 Another result from the Miller article is that when the amount of information a
561 human must interpret increases, it is crucial that the translation from one code
562 to another must be almost automatic for the subject to be able to remember the
563 translation, before \heshe is presented with new information to recode. Thus
564 learning and understanding how to best organize certain kinds of data is
565 essential to efficiently handle that kind of data in the future. This is much
566 like when humans learn to read. First they must learn how to recognize letters.
567 Then they can learn distinct words, and later read sequences of words that form
568 whole sentences. Eventually, most of them will be able to read whole books and
569 briefly retell the important parts of its content. This suggests that the use of
570 design patterns is a good idea when reasoning about computer programs. With
571 extensive use of design patterns when creating complex program structures, one
572 does not always have to read whole classes of code to comprehend how they
573 function, it may be sufficient to only see the name of a class to almost fully
574 understand its responsibilities.
577 Our language is tremendously useful for repackaging material into a few chunks
578 rich in information.~\cite[p.~95]{miller1956}
581 Without further evidence, these results at least indicate that refactoring
582 source code into smaller units with higher cohesion and, when needed,
583 introducing appropriate design patterns, should aid in the cause of creating
584 computer programs that are easier to maintain and have code that is easier (and
587 \subsection{Notable contributions to the refactoring literature}
590 \item[1992] William F. Opdyke submits his doctoral dissertation called
591 \tit{Refactoring Object-Oriented Frameworks}\citing{opdyke1992}. This work
592 defines a set of refactorings that are behavior-preserving given that their
593 preconditions are met. The dissertation is focused on the automation of
595 \item[1999] Martin Fowler et al.: \tit{Refactoring: Improving the Design of
596 Existing Code}\citing{refactoring}. This is maybe the most influential text
597 on refactoring. It bares similarities with Opdykes thesis\citing{opdyke1992}
598 in the way that it provides a catalog of refactorings. But Fowler's book is
599 more about the craft of refactoring, as he focuses on establishing a
600 vocabulary for refactoring, together with the mechanics of different
601 refactorings and when to perform them. His methodology is also founded on
602 the principles of test-driven development.
603 \item[2005] Joshua Kerievsky: \tit{Refactoring to
604 Patterns}\citing{kerievsky2005}. This book is heavily influenced by Fowler's
605 \tit{Refactoring}\citing{refactoring} and the ``Gang of Four'' \tit{Design
606 Patterns}\citing{designPatterns}. It is building on the refactoring
607 catalogue from Fowler's book, but is trying to bridge the gap between
608 \emph{refactoring} and \emph{design patterns} by providing a series of
609 higher-level composite refactorings, that makes code evolve toward or away
610 from certain design patterns. The book is trying to build up the reader's
611 intuition around \emph{why} one would want to use a particular design
612 pattern, and not just \emph{how}. The book is encouraging evolutionary
613 design \see{relationToDesignPatterns}.
616 \subsection{Tool support (for Java)}\label{toolSupport}
617 This section will briefly compare the refactoring support of the three IDEs
618 \name{Eclipse}\footnote{\url{http://www.eclipse.org/}}, \name{IntelliJ
619 IDEA}\footnote{The IDE under comparison is the \name{Community Edition},
620 \url{http://www.jetbrains.com/idea/}} and
621 \name{NetBeans}\footnote{\url{https://netbeans.org/}}. These are the most
622 popular Java IDEs\citing{javaReport2011}.
624 All three IDEs provide support for the most useful refactorings, like the
625 different extract, move and rename refactorings. In fact, Java-targeted IDEs are
626 known for their good refactoring support, so this did not appear as a big
629 The IDEs seem to have excellent support for the \ExtractMethod refactoring, so
630 at least they have all passed the first ``refactoring
631 rubicon''\citing{fowlerRubicon2001,secondRubicon2012}.
633 Regarding the \MoveMethod refactoring, the \name{Eclipse} and \name{IntelliJ}
634 IDEs do the job in very similar manners. In most situations they both do a
635 satisfying job by producing the expected outcome. But they do nothing to check
636 that the result does not break the semantics of the program
637 \see{sec:correctness}.
638 The \name{NetBeans} IDE implements this refactoring in a somewhat
639 unsophisticated way. For starters, the refactoring's default destination for the
640 move, is the same class as the method already resides in, although it refuses to
641 perform the refactoring if chosen. But the worst part is, that if moving the
642 method \method{f} of the class \type{C} to the class \type{X}, it will break the
643 code. The result is shown in \myref{lst:moveMethod_NetBeans}.
647 \begin{minted}[samepage]{java}
660 \begin{minted}[samepage]{java}
670 \caption{Moving method \method{f} from \type{C} to \type{X}.}
671 \label{lst:moveMethod_NetBeans}
674 \name{NetBeans} will try to create code that call the methods \method{m} and \method{n}
675 of \type{X} by accessing them through \var{c.x}, where \var{c} is a parameter of
676 type \type{C} that is added the method \method{f} when it is moved. (This is
677 seldom the desired outcome of this refactoring, but ironically, this ``feature''
678 keeps \name{NetBeans} from breaking the code in the example from
679 \myref{sec:correctness}.) If \var{c.x} for some reason is inaccessible to
680 \type{X}, as in this case, the refactoring breaks the code, and it will not
681 compile. \name{NetBeans} presents a preview of the refactoring outcome, but the
682 preview does not catch it if the IDE is about break the program.
684 The IDEs under investigation seem to have fairly good support for primitive
685 refactorings, but what about more complex ones, such as
686 \gloss{extractClass}\citing{refactoring}? \name{IntelliJ} handles this in a
687 fairly good manner, although, in the case of private methods, it leaves unused
688 methods behind. These are methods that delegate to a field with the type of the
689 new class, but are not used anywhere. \name{Eclipse} has added its own quirk to
690 the \refa{Extract Class} refactoring, and only allows for \emph{fields} to be
691 moved to a new class, \emph{not methods}. This makes it effectively only
692 extracting a data structure, and calling it \refa{Extract Class} is a little
693 misleading. One would often be better off with textual extract and paste than
694 using the \refa{Extract Class} refactoring in \name{Eclipse}. When it comes to
695 \name{NetBeans}, it does not even show an attempt on providing this refactoring.
697 \subsection{The relation to design patterns}\label{relationToDesignPatterns}
699 Refactoring and design patterns have at least one thing in common, they are both
700 promoted by advocates of \emph{clean code}\citing{cleanCode} as fundamental
701 tools on the road to more maintainable and extendable source code.
704 Design patterns help you determine how to reorganize a design, and they can
705 reduce the amount of refactoring you need to do
706 later.~\cite[p.~353]{designPatterns}
709 Although sometimes associated with
710 over-engineering\citing{kerievsky2005,refactoring}, design patterns are in
711 general assumed to be good for maintainability of source code. That may be
712 because many of them are designed to support the \emph{open/closed principle} of
713 object-oriented programming. The principle was first formulated by Bertrand
714 Meyer, the creator of the Eiffel programming language, like this: ``Modules
715 should be both open and closed.''\citing{meyer1988} It has been popularized,
716 with this as a common version:
719 Software entities (classes, modules, functions, etc.) should be open for
720 extension, but closed for modification.
723 Maintainability is often thought of as the ability to be able to introduce new
724 functionality without having to change too much of the old code. When
725 refactoring, the motivation is often to facilitate adding new functionality. It
726 is about factoring the old code in a way that makes the new functionality being
727 able to benefit from the functionality already residing in a software system,
728 without having to copy old code into new. Then, next time someone shall add new
729 functionality, it is less likely that the old code has to change. Assuming that
730 a design pattern is the best way to get rid of duplication and assist in
731 implementing new functionality, it is reasonable to conclude that a design
732 pattern often is the target of a series of refactorings. Having a repertoire of
733 design patterns can also help in knowing when and how to refactor a program to
734 make it reflect certain desired characteristics.
737 There is a natural relation between patterns and refactorings. Patterns are
738 where you want to be; refactorings are ways to get there from somewhere
739 else.~\cite[p.~107]{refactoring}
742 This quote is wise in many contexts, but it is not always appropriate to say
743 ``Patterns are where you want to be\ldots''. \emph{Sometimes}, patterns are
744 where you want to be, but only because it will benefit your design. It is not
745 true that one should always try to incorporate as many design patterns as
746 possible into a program. It is not like they have intrinsic value. They only add
747 value to a system when they support its design. Otherwise, the use of design
748 patterns may only lead to a program that is more complex than necessary.
751 The overuse of patterns tends to result from being patterns happy. We are
752 \emph{patterns happy} when we become so enamored of patterns that we simply
753 must use them in our code.~\cite[p.~24]{kerievsky2005}
756 This can easily happen when relying largely on up-front design. Then it is
757 natural, in the very beginning, to try to build in all the flexibility that one
758 believes will be necessary throughout the lifetime of a software system.
759 According to Joshua Kerievsky ``That sounds reasonable --- if you happen to be
760 psychic.''~\cite[p.~1]{kerievsky2005} He is advocating what he believes is a
761 better approach: To let software continually evolve. To start with a simple
762 design that meets today's needs, and tackle future needs by refactoring to
763 satisfy them. He believes that this is a more economic approach than investing
764 time and money into a design that inevitably is going to change. By relying on
765 continuously refactoring a system, its design can be made simpler without
766 sacrificing flexibility. To be able to fully rely on this approach, it is of
767 utter importance to have a reliable suit of tests to lean on \see{testing}. This
768 makes the design process more natural and less characterized by difficult
769 decisions that has to be made before proceeding in the process, and that is
770 going to define a project for all of its unforeseeable future.
772 \subsection{The impact on software quality}
774 \subsubsection{What is software quality?}
775 The term \emph{software quality} has many meanings. It all depends on the
776 context we put it in. If we look at it with the eyes of a software developer, it
777 usually means that the software is easily maintainable and testable, or in other
778 words, that it is \emph{well designed}. This often correlates with the
779 management scale, where \emph{keeping the schedule} and \emph{customer
780 satisfaction} is at the center. From the customers point of view, in addition to
781 good usability, \emph{performance} and \emph{lack of bugs} is always
782 appreciated, measurements that are also shared by the software developer. (In
783 addition, such things as good documentation could be measured, but this is out
784 of the scope of this document.)
786 \subsubsection{The impact on performance}
788 Refactoring certainly will make software go more slowly\footnote{With today's
789 compiler optimization techniques and performance tuning of e.g. the Java
790 virtual machine, the penalties of object creation and method calls are
791 debatable.}, but it also makes the software more amenable to performance
792 tuning.~\cite[p.~69]{refactoring}
795 \noindent There is a common belief that refactoring compromises performance, due
796 to increased degree of indirection and that polymorphism is slower than
799 In a survey, Demeyer\citing{demeyer2002} disproves this view in the case of
800 polymorphism. He did an experiment on, what he calls, ``Transform Self Type
801 Checks'' where you introduce a new polymorphic method and a new class hierarchy
802 to get rid of a class' type checking of a ``type attribute``. He uses this kind
803 of transformation to represent other ways of replacing conditionals with
804 polymorphism as well. The experiment is performed on the C++ programming
805 language and with three different compilers and platforms. Demeyer concludes
806 that, with compiler optimization turned on, polymorphism beats middle to large
807 sized if-statements and does as well as case-statements. (In accordance with
808 his hypothesis, due to similarities between the way C++ handles polymorphism and
812 The interesting thing about performance is that if you analyze most programs,
813 you find that they waste most of their time in a small fraction of the
814 code.~\cite[p.~70]{refactoring}
817 \noindent So, although an increased amount of method calls could potentially
818 slow down programs, one should avoid premature optimization and sacrificing good
819 design, leaving the performance tuning until after \gloss{profiling} the
820 software and having isolated the actual problem areas.
822 \subsection{Composite refactorings}\label{compositeRefactorings}
823 Generally, when thinking about refactoring, at the mechanical level, there are
824 essentially two kinds of refactorings. There are the \emph{primitive}
825 refactorings, and the \emph{composite} refactorings.
827 \definition{A \emph{primitive refactoring} is a refactoring that cannot be
828 expressed in terms of other refactorings.}
830 \noindent Examples are the \refa{Pull Up Field} and \refa{Pull Up
831 Method} refactorings\citing{refactoring}, that move members up in their class
834 \definition{A \emph{composite refactoring} is a refactoring that can be
835 expressed in terms of two or more other refactorings.}
837 \noindent An example of a composite refactoring is the \refa{Extract
838 Superclass} refactoring\citing{refactoring}. In its simplest form, it is composed
839 of the previously described primitive refactorings, in addition to the
840 \refa{Pull Up Constructor Body} refactoring\citing{refactoring}. It works
841 by creating an abstract superclass that the target class(es) inherits from, then
842 by applying \refa{Pull Up Field}, \refa{Pull Up Method} and
843 \refa{Pull Up Constructor Body} on the members that are to be members of
844 the new superclass. If there are multiple classes in play, their interfaces may
845 need to be united with the help of some rename refactorings, before extracting
846 the superclass. For an overview of the \refa{Extract Superclass}
847 refactoring, see \myref{fig:extractSuperclass}.
851 \includegraphics[angle=270,width=\linewidth]{extractSuperclassItalic.pdf}
852 \caption{The Extract Superclass refactoring, with united interfaces. (Taken
853 from \url{http://refactoring.com/catalog/extractSuperclass.html}.)}
854 \label{fig:extractSuperclass}
857 \subsection{Manual vs. automated refactorings}
858 Refactoring is something every programmer does, even if \heshe does not known
859 the term \emph{refactoring}. Every refinement of source code that does not alter
860 the program's behavior is a refactoring. For small refactorings, such as
861 \ExtractMethod, executing it manually is a manageable task, but is still prone
862 to errors. Getting it right the first time is not easy, considering the method
863 signature and all the other aspects of the refactoring that has to be in place.
865 Consider the renaming of classes, methods and fields. For complex programs these
866 refactorings are almost impossible to get right. Attacking them with textual
867 search and replace, or even regular expressions, will fall short on these tasks.
868 Then it is crucial to have proper tool support that can perform them
869 automatically. Tools that can parse source code and thus have semantic knowledge
870 about which occurrences of which names belong to what construct in the program.
871 For even trying to perform one of these complex tasks manually, one would have
872 to be very confident on the existing test suite \see{testing}.
874 \subsection{Correctness of refactorings}\label{sec:correctness}
875 For automated refactorings to be truly useful, they must show a high degree of
876 behavior preservation. This last sentence might seem obvious, but there are
877 examples of refactorings in existing tools that break programs. In an ideal
878 world, every automated refactoring would be ``complete'', in the sense that it
879 would never break a program. In an ideal world, every program would also be free
880 from bugs. In modern IDEs the implemented automated refactorings are working for
881 \emph{most} cases, which is enough for making them useful.
883 I will now present an example of a \emph{corner case} where a program breaks
884 when a refactoring is applied. The example shows an \ExtractMethod refactoring
885 followed by a \MoveMethod refactoring that breaks a program in both the
886 \name{Eclipse} and \name{IntelliJ} IDEs\footnote{The \name{NetBeans} IDE handles this
887 particular situation without altering the program's behavior, mainly because
888 its \refa{Move Method} refactoring implementation is a bit flawed in other ways
889 \see{toolSupport}.}. The target and the destination for the composed
890 refactoring are shown in \myref{lst:correctnessExtractAndMove}. Note that the
891 method \method{m(C c)} of class \type{X} assigns to the field \var{x} of the
892 argument \var{c} that has type \type{C}.
896 \begin{minted}[linenos,frame=topline,label={Refactoring
897 target},framesep=\mintedframesep]{java}
899 public X x = new X();
911 \begin{minted}[frame=topline,label={Method
912 destination},framesep=\mintedframesep]{java}
916 // If m is called from
917 // c, then c.x no longer
924 \caption{The target and the destination for the composition of the Extract
925 Method and \refa{Move Method} refactorings.}
926 \label{lst:correctnessExtractAndMove}
930 The refactoring sequence works by extracting line 6 through 8 from the original
931 class \type{C} into a method \method{f} with the statements from those lines as
932 its method body (but with the comment left out, since it will no longer hold any
933 meaning). The method is then moved to the class \type{X}. The result is shown
934 in \myref{lst:correctnessExtractAndMoveResult}.
936 Before the refactoring, the methods \method{m} and \method{n} of class \type{X}
937 are called on different object instances (see line 6 and 8 of the original class
938 \type{C} in \cref{lst:correctnessExtractAndMove}). After the refactoring, they
939 are called on the same object, and the statement on line
940 3 of class \type{X} (in \cref{lst:correctnessExtractAndMoveResult}) no longer
941 has the desired effect in our example. The method \method{f} of class \type{C}
942 is now calling the method \method{f} of class \type{X} (see line 5 of class
943 \type{C} in \cref{lst:correctnessExtractAndMoveResult}), and the program now
944 behaves different than before.
948 \begin{minted}[linenos]{java}
950 public X x = new X();
960 \begin{minted}[linenos]{java}
975 \caption{The result of the composed refactoring.}
976 \label{lst:correctnessExtractAndMoveResult}
979 The bug introduced in the previous example is of such a nature\footnote{Caused
980 by aliasing.} that it is very difficult to spot if the refactored code is not
981 covered by tests. It does not generate compilation errors, and will thus only
982 result in a runtime error or corrupted data, which might be hard to detect.
984 \subsection{Refactoring and the importance of testing}\label{testing}
986 If you want to refactor, the essential precondition is having solid
987 tests.\citing{refactoring}
990 When refactoring, there are roughly three classes of errors that can be made.
991 The first class of errors is the one that makes the code unable to compile.
992 These \emph{compile-time} errors are of the nicer kind. They flash up at the
993 moment they are made (at least when using an IDE), and are usually easy to fix.
994 The second class is the \emph{runtime} errors. Although these errors take a bit
995 longer to surface, they usually manifest after some time in an illegal argument
996 exception, null pointer exception or similar during the program execution.
997 These kinds of errors are a bit harder to handle, but at least they will show,
998 eventually. Then there are the \emph{behavior-changing} errors. These errors are
999 of the worst kind. They do not show up during compilation and they do not turn
1000 on a blinking red light during runtime either. The program can seem to work
1001 perfectly fine with them in play, but the business logic can be damaged in ways
1002 that will only show up over time.
1004 For discovering runtime errors and behavior changes when refactoring, it is
1005 essential to have good test coverage. Testing in this context means writing
1006 automated tests. Manual testing may have its uses, but when refactoring, it is
1007 automated unit testing that dominate. For discovering behavior changes it is
1008 especially important to have tests that cover potential problems, since these
1009 kinds of errors do not reveal themselves.
1011 Unit testing is not a way to \emph{prove} that a program is correct, but it is a
1012 way to make you confident that it \emph{probably} works as desired. In the
1013 context of test-driven development (commonly known as TDD), the tests are even a
1014 way to define how the program is \emph{supposed} to work. It is then, by
1015 definition, working if the tests are passing.
1017 If the test coverage for a code base is perfect, then it should, theoretically,
1018 be risk-free to perform refactorings on it. This is why automated tests and
1019 refactoring is such a great match.
1021 \subsubsection{Testing the code from correctness section}
1022 The worst thing that can happen when refactoring is to introduce changes to the
1023 behavior of a program, as in the example on \myref{sec:correctness}. This
1024 example may be trivial, but the essence is clear. The only problem with the
1025 example is that it is not clear how to create automated tests for it, without
1026 changing it in intrusive ways.
1028 Unit tests, as they are known from the different \glosspl{xUnit} around, are
1029 only suitable to test the \emph{result} of isolated operations. They can not
1030 easily (if at all) observe the \emph{history} of a program.
1032 This problem is still open.
1036 Assuming a sequential (non-concurrent) program:
1038 \begin{minted}{java}
1039 tracematch (C c, X x) {
1041 call(* X.m(C)) && args(c) && cflow(within(C));
1043 call(* X.n()) && target(x) && cflow(within(C));
1045 set(C.x) && target(c) && !cflow(m);
1049 { assert x == c.x; }
1053 %\begin{minted}{java}
1054 %tracematch (X x1, X x2) {
1056 % call(* X.m(C)) && target(x1);
1058 % call(* X.n()) && target(x2);
1060 % set(C.x) && !cflow(m) && !cflow(n);
1064 % { assert x1 != x2; }
1070 \section{The project}\label{sec:project}
1071 In this section we look at the work that will be done for this project, its
1072 building blocks, pose some research questions and present some of the
1075 \subsection{Project description}
1076 The aim of this master's project will be to explore the relationship between the
1077 \ExtractMethod and the \MoveMethod refactorings. This will be done by composing
1078 the two into a composite refactoring. The refactoring will be called the
1079 \ExtractAndMoveMethod refactoring.
1081 The two primitive refactorings \ExtractMethod and \MoveMethod must already be
1082 implemented in a tool, so the \ExtractAndMoveMethod refactoring can be built on
1085 The composition of the \ExtractMethod and \MoveMethod refactorings springs
1086 naturally out of the need to move procedures closer to the data they manipulate.
1087 This composed refactoring is not well described in the literature, but it is
1088 implemented in at least one tool called
1089 \href{https://help.devexpress.com/\#CodeRush/CustomDocument3519}{\name{CodeRush}},
1090 which is an extension for \href{http://www.visualstudio.com/}{\name{MS Visual
1091 Studio}}. In CodeRush it is called \refa{Extract Method to
1092 Type}\footnote{\url{https://help.devexpress.com/\#CodeRush/CustomDocument6710}},
1093 but I choose to call it \ExtractAndMoveMethod, since I feel this better
1094 communicates which primitive refactorings it is composed of.
1096 The project will consist of implementing the \ExtractAndMoveMethod refactoring,
1097 as well as executing it over a larger code base, as a case study. To be able to
1098 execute the refactoring automatically, I have to make it analyze code to
1099 determine the best selections to extract into new methods.
1101 \subsection{The premises}
1102 Before we can start manipulating source code, and write a tool for doing so, we
1103 need to decide on a programming language for the code we are going to
1104 manipulate. Also, since we do not want to start from scratch by implementing
1105 primitive refactorings ourselves, we need to choose an existing tool that
1106 provides the needed refactorings. In addition to be able to perform changes, we
1107 need a framework for analyzing source code for the language we select.
1109 \subsubsection{Choosing the target language}
1110 Choosing which programming language the code that will be manipulated shall be
1111 written in, is not a very difficult task. We choose to limit the possible
1112 languages to the object-oriented programming languages, since most of the
1113 terminology and literature regarding refactoring comes from the world of
1114 object-oriented programming. In addition, the language must have existing tool
1115 support for refactoring.
1117 The \href{https://www.java.com/}{\name{Java} programming language} is the
1118 dominating language when it comes to example code in the literature of
1119 refactoring, and is thus a natural choice. Java is perhaps the most influential
1120 programming language in the world today, with its \name{Java Virtual Machine}
1121 that runs on all of the most popular computer architectures and also supports
1122 dozens of other programming languages\footnote{They compile to Java bytecode.},
1123 with \name{Scala}, \name{Clojure} and \name{Groovy} as the most prominent ones.
1124 Java is currently the language that every other programming language is compared
1125 against. It is also the primary programming language for the author of this
1128 \subsubsection{Choosing the tools}
1129 When choosing a tool for manipulating Java, there are certain criteria that
1130 have to be met. First of all, the tool should have some existing refactoring
1131 support that this thesis can build upon. Secondly, it should provide some kind
1132 of framework for parsing and analyzing Java source code. Third, it should itself
1133 be open source. This is both because of the need to be able to browse the code
1134 for the existing refactorings that is contained in the tool, and also because
1135 open source projects hold value in them selves. Another important aspect to
1136 consider, is that open source projects of a certain size usually has large
1137 communities of people connected to them, which are committed to answering
1138 questions regarding the use and misuse of the products, that to a large degree
1139 is made by the community itself.
1141 There is a certain class of tools that meet these criteria, namely the class of
1142 \emph{IDEs}\footnote{\emph{Integrated Development Environment}}. These are
1143 programs that are meant to support the whole production cycle of a computer
1144 program, and the most popular IDEs that support Java generally have quite good
1145 refactoring support.
1147 The main contenders for this thesis are the \name{Eclipse IDE}, with the
1148 \name{Java development tools} (JDT), the \name{IntelliJ IDEA Community Edition}
1149 and the \name{NetBeans IDE} \see{toolSupport}. \name{Eclipse} and
1150 \name{NetBeans} are both free, open source and community driven, while the
1151 \name{IntelliJ IDEA} has an open-sourced community edition that is free of
1152 charge, but also offers an \name{Ultimate Edition} with an extended set of
1153 features, at additional cost. All three IDEs supports adding plugins to extend
1154 their functionality and tools that can be used to parse and analyze Java source
1155 code. But one of the IDEs stand out as a favorite, and that is the \name{Eclipse
1156 IDE}. This is the most popular\citing{javaReport2011} among the three and seems
1157 to be de facto standard IDE for Java development regardless of platform.
1160 \subsection{The primitive refactorings}
1161 The refactorings presented here are the primitive refactorings used in this
1162 project. They are the abstract building blocks used by the \ExtractAndMoveMethod
1165 \paragraph{The Extract Method refactoring.}
1166 The \refa{Extract Method} refactoring\citing{refactoring} is used to extract
1167 a fragment of code from its context and into a new method. A call to the new
1168 method is inlined where the fragment was before. It is used to break code into
1169 logical units, with names that explain their purpose.
1171 An example of an \ExtractMethod refactoring is shown in
1172 \myref{lst:extractMethodRefactoring}. It shows a method containing calls to the
1173 methods \method{foo} and \method{bar} of a type \type{X}. These statements are
1174 then extracted into the new method \method{fooBar}.
1177 \def\charwidth{5.8pt}
1178 \def\indent{2*\charwidth}
1179 \def\rightColX{32*\charwidth}
1180 \def\lineheight{\baselineskip}
1181 \def\mintedtop{2*\lineheight+5.8pt}
1183 \begin{tikzpicture}[overlay, yscale=-1]
1184 \tikzstyle{overlaybox}=[fill=lightgray,opacity=0.2]
1186 \draw[overlaybox] (\indent,\mintedtop+\lineheight*3) rectangle
1187 +(19*\charwidth,\lineheight);
1190 \draw[overlaybox] (\rightColX+\indent,\mintedtop+\lineheight*3) rectangle
1191 +(16*\charwidth,\lineheight);
1193 \draw[overlaybox] (\rightColX,\mintedtop+\lineheight*5) rectangle
1194 +(21*\charwidth,3*\lineheight);
1196 \begin{multicols}{2}
1197 \begin{minted}[samepage,frame=topline,label={Before},framesep=\mintedframesep]{java}
1208 \begin{minted}[samepage,frame=topline,label={After},framesep=\mintedframesep]{java}
1220 \caption{An example of an \ExtractMethod refactoring.}
1221 \label{lst:extractMethodRefactoring}
1224 \paragraph{The Move Method refactoring.}
1225 The \refa{Move Method} refactoring\citing{refactoring} is used to move a method
1226 from one class to another. This can be appropriate if the method is using more
1227 features of another class than of the class in which it is currently defined.
1229 \Myref{lst:moveMethodRefactoring} shows an example of this refactoring. Here, a
1230 method \method{fooBar} is moved from a class \type{C} to a class \type{X}.
1233 \def\charwidth{5.8pt}
1234 \def\indent{2*\charwidth}
1235 \def\rightColX{32*\charwidth}
1236 \def\lineheight{\baselineskip}
1237 \def\mintedtop{2*\lineheight+5.8pt}
1239 \begin{tikzpicture}[overlay, yscale=-1]
1240 \tikzstyle{overlaybox}=[fill=lightgray,opacity=0.2]
1242 \draw[overlaybox] (0,\mintedtop+\lineheight*5) rectangle
1243 +(21*\charwidth,3*\lineheight);
1246 \draw[overlaybox] (\rightColX,\mintedtop+\lineheight*10) rectangle
1247 +(22*\charwidth,3*\lineheight);
1249 \begin{multicols}{2}
1250 \begin{minted}[samepage,frame=topline,label={Before},framesep=\mintedframesep]{java}
1269 \begin{minted}[samepage,frame=topline,label={After},framesep=\mintedframesep]{java}
1286 \caption{An example of a \MoveMethod refactoring.}
1287 \label{lst:moveMethodRefactoring}
1290 \subsection{The Extract and Move Method refactoring}
1291 The \ExtractAndMoveMethod refactoring is a composite refactoring composed of the
1292 primitive refactorings \ExtractMethod and \MoveMethod. The effect of this
1293 refactoring on source code is the same as when extracting a method and moving it
1294 to another class. Conceptually, this is done without an intermediate step. In
1295 practice, as we shall see later, an intermediate step may be necessary.
1297 An example of this composite refactoring is shown in
1298 \myref{lst:extractAndMoveMethodRefactoring}. The example joins the examples from
1299 \cref{lst:extractMethodRefactoring} and \cref{lst:moveMethodRefactoring}. This
1300 means that the selection consisting of the consecutive calls to the methods
1301 \method{foo} and \method{bar}, is extracted into a new method \method{fooBar}
1302 located in the class \type{X}.
1305 \def\charwidth{5.8pt}
1306 \def\indent{2*\charwidth}
1307 \def\rightColX{32*\charwidth}
1308 \def\lineheight{\baselineskip}
1309 \def\mintedtop{2*\lineheight+5.8pt}
1311 \begin{tikzpicture}[overlay, yscale=-1]
1312 \tikzstyle{overlaybox}=[fill=lightgray,opacity=0.2]
1314 \draw[overlaybox] (\indent,\mintedtop+\lineheight*3) rectangle
1315 +(19*\charwidth,\lineheight);
1318 \draw[overlaybox] (\rightColX+\indent,\mintedtop+\lineheight*3) rectangle
1319 +(16*\charwidth,\lineheight);
1321 \draw[overlaybox] (\rightColX,\mintedtop+\lineheight*10) rectangle
1322 +(22*\charwidth,3*\lineheight);
1324 \begin{multicols}{2}
1325 \begin{minted}[samepage,frame=topline,label={Before},framesep=\mintedframesep]{java}
1341 \begin{minted}[samepage,frame=topline,label={After},framesep=\mintedframesep]{java}
1358 \caption{An example of the \ExtractAndMoveMethod refactoring.}
1359 \label{lst:extractAndMoveMethodRefactoring}
1362 \subsection{The Coupling Between Object Classes metric}\label{sec:CBO}
1363 The best known metric for measuring coupling between classes in object-oriented
1364 software is called \metr{Coupling Between Object Classes}, usually abbreviated
1365 as CBO. The metric is defined in the article \tit{A Metrics Suite for Object
1366 Oriented Design}\citing{metricsSuite1994} by Chidamber and Kemerer, published in
1369 \definition{\emph{CBO} for a class is a count of the number of other classes to
1370 which it is coupled.}
1372 An object is coupled to another object if one of them acts on the other by using
1373 methods or instance variables of the other object. This relation goes both ways,
1374 so both outgoing and incoming uses are counted. Each coupling relationship is
1375 only considered once when measuring CBO for a class.
1377 \paragraph{How can the Extract and Move Method refactoring improve CBO?}
1378 \Myref{lst:CBOExample} shows how CBO changes for a class when it is refactored
1379 with the \ExtractAndMoveMethod refactoring. In the example we consider only the
1380 CBO value of class \type{C}.
1383 \def\charwidth{5.8pt}
1384 \def\indent{2*\charwidth}
1385 \def\rightColX{32*\charwidth}
1386 \def\lineheight{\baselineskip}
1387 \def\mintedtop{2*\lineheight+5.8pt}
1389 \begin{tikzpicture}[overlay, yscale=-1]
1390 \tikzstyle{overlaybox}=[fill=lightgray,opacity=0.2]
1392 \draw[overlaybox] (\indent,\mintedtop+\lineheight*4) rectangle
1393 +(15*\charwidth,2*\lineheight);
1396 \draw[overlaybox] (\rightColX+\indent,\mintedtop+\lineheight*4) rectangle
1397 +(15*\charwidth,\lineheight);
1399 \draw[overlaybox] (\rightColX,\mintedtop+\lineheight*15) rectangle
1400 +(19*\charwidth,4*\lineheight);
1402 \begin{multicols}{2}
1403 \begin{minted}[linenos,samepage,frame=topline,label={Before},framesep=\mintedframesep]{java}
1434 \begin{minted}[linenos,samepage,frame=topline,label={After},framesep=\mintedframesep]{java}
1466 \caption{An example of improving CBO. Class \type{C} has a CBO value of 4
1467 before refactoring it, and 3 after.}
1468 \label{lst:CBOExample}
1471 Before refactoring the class \type{C} with the \ExtractAndMoveMethod
1472 refactoring, it has a CBO value of 4. The class uses members of the classes
1473 \type{A} and \type{B}, which accounts for 2 of the coupling relationships of
1474 class \type{C}. In addition to this, it uses its variable \var{x} with type
1475 \type{X} and also the methods \method{foo} and \method{bar} declared in class
1476 \type{Y}, giving it a total CBO value of 4.
1478 The after-part of the example code in \mysimpleref{lst:CBOExample} shows the
1479 result of extracting the lines
1480 5 and 6 of class \type{C} into a new method \method{fooBar}, with a subsequent
1481 move of it to class \type{X}.
1483 With respect to the CBO metric, the refactoring action accomplishes something
1484 important: It eliminates the uses of class \type{Y} from class \type{C}. This
1485 means that the class \type{C} is no longer coupled to \type{Y}, only the classes
1486 \type{A}, \type{B} and \type{X}. The CBO value of class \type{C} is therefore 3
1487 after the refactoring, while no other class have received any increase in CBO.
1489 The example shown here is an ideal situation. Coupling is reduced for one class
1490 without any increase of coupling for another class. There is also another
1491 important point: It is the fact that to reduce the CBO value for a class, we
1492 need to remove \emph{all} its uses of another class. This is done for the class
1493 \type{C} in \myref{lst:CBOExample}, where all uses of class \type{Y} is removed
1494 by the \ExtractAndMoveMethod refactoring.
1497 \subsection{Research questions}\label{sec:researchQuestions}
1498 The main question that I seek an answer to in this thesis is:
1501 Is it possible to automate the analysis and execution of the
1502 \ExtractAndMoveMethod refactoring, and do so for all of the code of a larger
1506 \noindent The secondary questions will then be:
1508 \paragraph{Can we do this efficiently?} Can we automate the analysis and
1509 execution of the refactoring so it can be run in a reasonable amount of time?
1511 \paragraph{Can we perform changes safely?} Can we take actions to prevent the
1512 refactoring from breaking code? By ``breaking code'' we mean to either do
1513 changes that do not compile, or make changes that alter the behavior of a
1516 \paragraph{Can we improve the quality of source code?} Assuming that the
1517 refactoring is safe: Is it feasible to assure that code we refactor actually
1518 gets better in terms of coupling?
1520 \paragraph{How can the automation of the refactoring be helpful?} Assuming the
1521 refactoring does in fact improve the quality of source code and is safe to use:
1522 What is the usefulness of the refactoring in a software development setting? In
1523 what parts of the development process can the refactoring play a role?
1525 \subsection{Methodology}
1526 This section will present some of the methodologies used during the work of this
1529 \subsubsection{Evolutionary design}
1530 In the programming work for this project, I have tried using a design strategy
1531 called evolutionary design, also known as continuous or incremental
1532 design\citing{wiki_continuous_2014}. It is a software design strategy advocated
1533 by the Extreme Programming community. The essence of the strategy is that you
1534 should let the design of your program evolve naturally as your requirements
1535 change. This is seen in contrast with up-front design, where design decisions
1536 are made early in the process.
1538 The motivation behind evolutionary design is to keep the design of software as
1539 simple as possible. This means not introducing unneeded functionality into a
1540 program. You should defer introducing flexibility into your software, until it
1541 is needed to be able to add functionality in a clean way.
1543 Holding up design decisions, implies that the time will eventually come when
1544 decisions have to be made. The flexibility of the design then relies on the
1545 programmer's abilities to perform the necessary refactoring, and \his confidence
1546 in those abilities. From my experience working on this project, I can say that
1547 this confidence is greatly enhanced by having automated tests to rely on
1550 The choice of going for evolutionary design developed naturally. As Fowler
1551 points out in his article \tit{Is Design Dead?}, evolutionary design much
1552 resembles the ``code and fix'' development strategy\citing{fowler_design_2004}.
1553 A strategy which most of us have practiced in school. This was also the case
1554 when I first started this work. I had to learn the inner workings of Eclipse and
1555 its refactoring-related plugins. That meant a lot of fumbling around with code I
1556 did not know, in a trial and error fashion. Eventually I started writing tests
1557 for my code, and my design began to evolve.
1559 \subsubsection{Test-driven development}\label{tdd}
1560 As mentioned before, the project started out as a classic code and fix
1561 development process. My focus was aimed at getting something to work, rather
1562 than doing so according to best practice. This resulted in a project that got
1563 out of its starting blocks, but it was not accompanied by any tests. Hence it
1564 was soon difficult to make any code changes with the confidence that the program
1565 was still correct afterwards (assuming it was so before changing it). I always
1566 knew that I had to introduce some tests at one point, but this experience
1567 accelerated the process of leading me onto the path of testing.
1569 I then wrote tests for the core functionality of the plugin, and thus gained
1570 more confidence in the correctness of my code. I could now perform quite drastic
1571 changes without ``wetting my pants``. After this, nearly all of the semantic
1572 changes done to the business logic of the project, or the addition of new
1573 functionality, were made in a test-driven manner. This means that before
1574 performing any changes, I would define the desired functionality through a set
1575 of tests. I would then run the tests to check that they were run and that they
1576 did not pass. Then I would do any code changes necessary to make the tests
1577 pass. The definition of how the program is supposed to operate is then captured
1578 by the tests. However, this does not prove the correctness of the analysis
1579 leading to the test definitions.
1581 \subsubsection{Case studies}
1582 The case study methodology is used to show how the \ExtractAndMoveMethod
1583 refactoring performs on real code, not just toy examples. The case studies are
1584 used to analyze our project so we can conclude on its completeness and
1587 \subsubsection{Dogfooding}
1588 Dogfooding is a methodology where you use your own tools to do your job, also
1589 referred to as ``eating your own dog food''\citing{harrisonDogfooding2006}. It
1590 is used in this project to see if we can refactor our own refactoring code and
1591 still use it to refactor other code.
1593 \section{Related work}\label{sec:relatedWork}
1594 Here, some work is presented that relate to automated composition of
1597 \subsection{Search-based refactoring}
1598 \tit{Search-Based Refactoring: an
1599 empirical study}\citing{okeeffeSearchBased2008} is a paper by Mark O'Keeffe and
1600 Mel Ó Cinnéide published in 2008. The authors present an empirical study of
1601 different algorithmic approaches to search-based refactoring.
1603 The common approach for all these algorithms is to generate a set of changes to
1604 a program for then to use a ``fitness function'' to evaluate if they improve its
1605 design or not. The fitness function consists of a weighted sum of different
1606 object-oriented metrics.
1608 Among other things, the authors conclude that even with small input programs,
1609 their solution representation is memory-intensive, at least for some algorithms.
1610 The programs they refactor on have in average 4,000 lines of code, spread over
1611 57 classes. I.e. considerably smaller than one of the programs that will be
1612 subject to refactoring in this project.
1614 \subsection{``Making Program Refactoring
1615 Safer''}\label{sec:saferRefactoringTests}
1616 This is the name of an article\citing{soaresSafer2010} about providing a way to
1617 improve safety during refactoring. Soares et al. approaches the problem of
1618 preserving behavior during refactoring by analyzing a transformation and then
1619 generate a test suite for it, using static analysis. These tests are then run
1620 for both the before- and after-code, and is compared to assure that they are
1623 \subsection{The compositional paradigm of refactoring}
1624 This paradigm builds upon the observation of Vakilian et
1625 al.\citing{vakilian2012}, that of the many automated refactorings existing in
1626 modern IDEs, the simplest ones are dominating the usage statistics. The report
1627 mainly focuses on \name{Eclipse} as the tool under investigation.
1629 The paradigm is described almost as the opposite of automated composition of
1630 refactorings \see{compositeRefactorings}. It works by providing the programmer
1631 with easily accessible primitive refactorings. These refactorings shall be
1632 accessed via keyboard shortcuts or quick-assist menus\footnote{Think
1633 quick-assist with Ctrl+1 in \name{Eclipse}} and be promptly executed, opposed to in the
1634 currently dominating wizard-based refactoring paradigm. They are meant to
1635 stimulate composing smaller refactorings into more complex changes, rather than
1636 doing a large upfront configuration of a wizard-based refactoring, before
1637 previewing and executing it. The compositional paradigm of refactoring is
1638 supposed to give control back to the programmer, by supporting \himher with an
1639 option of performing small rapid changes instead of large changes with a lesser
1640 degree of control. The report authors hope this will lead to fewer unsuccessful
1641 refactorings. It also could lower the bar for understanding the steps of a
1642 larger composite refactoring and thus also helps in figuring out what goes wrong
1643 if one should choose to opt in on a wizard-based refactoring.
1645 Vakilian and his associates have performed a survey of the effectiveness of the
1646 compositional paradigm versus the wizard-based. They claim to have found
1647 evidence of the \emph{compositional paradigm} outperforming the
1648 \emph{wizard-based}. It does so by reducing automation, which seems
1649 counterintuitive. Therefore they ask the question ``What is an appropriate level
1650 of automation?'', and thus challenging what they feel is a rush toward more
1651 automation in the software engineering community.
1653 \chapter{The search-based Extract and Move Method
1654 refactoring}\label{ch:extractAndMoveMethod}
1655 In this chapter I will delve into the workings of the search-based
1656 \ExtractAndMoveMethod refactoring. We will see the choices it must make along
1657 the way and why it chooses a text selection as a candidate for refactoring or
1660 After defining some concepts, I will introduce an example that will be used
1661 throughout the chapter to illustrate how the refactoring works in some simple
1664 \section{The inputs to the refactoring}
1665 For executing an \ExtractAndMoveMethod refactoring, there are two simple
1666 requirements. The first thing the refactoring needs is a text selection, telling
1667 it what to extract. Its second requirement is a target for the subsequent move
1670 When the refactoring performs changes to source code, the extracted method must
1671 be called in place of the selection that now makes up the method's body. Also,
1672 the method call has to be performed via a variable, since the method is not
1673 static \see{par:ignoringStatic}. Therefore, the move target must be a local
1674 variable or a field in the scope of the text selection. The actual new location
1675 for the extracted method will be the class representing the type of the move
1678 \section{Defining a text selection}
1679 A text selection, in our context, is very similar to what you think of when
1680 selecting a bit of text in your editor or other text processing tool with your
1681 mouse or keyboard. It is an abstract construct that is meant to capture which
1682 specific portion of text we are about to deal with.
1684 To be able to clearly reason about a text selection done to a portion of text in
1685 a computer file, which consists of pure text, we put up the following
1688 \definition{A \emph{text selection} in a text file is defined by two
1689 non-negative integers, in addition to a reference to the file itself. The first
1690 integer is an offset into the file, while the second reference is the length of
1691 the text selection.}
1693 This means that the selected text consist of a number of characters equal to the
1694 length of the selection, where the first character is found at the specified
1697 \section{Where we look for text selections}
1699 \subsection{Text selections are found in methods}
1700 The text selections we are interested in are those that surround program
1701 statements. Therefore, the place we look for selections that can form candidates
1702 for an execution of the \ExtractAndMoveMethod refactoring, is within the body of
1705 \paragraph{On ignoring static methods.}\label{par:ignoringStatic}
1706 In this project we are not analyzing static methods for candidates to the
1707 \ExtractAndMoveMethod refactoring. The reason for this is that in the cases
1708 where we want to perform the refactoring for a selection within a static method,
1709 the first step is to extract the selection into a new method. Hence this method
1710 also becomes static, since it must be possible to call it from a static context.
1711 It would then be difficult to move the method to another class, make it
1712 non-static and calling it through a variable. To avoid these obstacles, we
1713 simply ignore static methods.
1715 \begin{listing}[htb]
1716 \def\charwidth{5.8pt}
1717 \def\indent{2*\charwidth}
1718 \def\lineheight{\baselineskip}
1719 \def\mintedtop{2*\lineheight+5.8pt}
1721 \begin{tikzpicture}[overlay, yscale=-1, xshift=3.8pt+\charwidth*31]
1722 \tikzstyle{overlaybox}=[fill=lightgray,opacity=0.2]
1724 \draw[overlaybox] (\indent,\mintedtop+\lineheight*4) rectangle
1725 +(23*\charwidth,17*\lineheight);
1728 \draw[overlaybox] (2*\indent,\mintedtop+5*\lineheight) rectangle
1729 +(15*\charwidth,3*\lineheight);
1730 \draw[overlaybox] (2*\indent,\mintedtop+15*\lineheight) rectangle
1731 +(15*\charwidth,3*\lineheight);
1732 \draw[overlaybox] (2*\indent,\mintedtop+19*\lineheight) rectangle
1733 +(15*\charwidth,\lineheight);
1735 \begin{multicols}{2}
1736 \begin{minted}[linenos,frame=topline,label=Clean,framesep=\mintedframesep]{java}
1738 A a; B b; boolean bool;
1740 void method(int val) {
1764 \begin{minted}[frame=topline,label={With statement
1765 sequences},framesep=\mintedframesep]{java}
1767 A a; B b; boolean bool;
1769 void method(int val) {
1792 \caption{Classes \type{A} and \type{B} are both public. The methods
1793 \method{foo} and \method{bar} are public members of class \type{A}.}
1794 \label{lst:grandExample}
1797 \subsection{The possible text selections of a method body}
1798 The number of possible text selections that can be made from the text in a
1799 method body, are equal to all the sub-sequences of characters within it. For our
1800 purposes, analyzing program source code, we must define what it means for a text
1801 selection to be valid.
1803 \definition{A \emph{valid text selection} is a text selection that contains all
1804 of one or more consecutive program statements.}
1806 For a sequence of statements, the text selections that can be made from it, are
1807 equal to all its sub-sequences. \Myref{lst:textSelectionsExample} show an
1808 example of all the text selections that can be made from the code in
1809 \myref{lst:grandExample}, lines 16-18. For convenience and the clarity of this
1810 example, the text selections are represented as tuples with the start and end
1811 line of all selections: $\{(16), (17), (18), (16,17), (16,18), (17,18)\}$.
1813 \begin{listing}[htb]
1814 \def\charwidth{5.7pt}
1815 \def\indent{4*\charwidth}
1816 \def\lineheight{\baselineskip}
1817 \def\mintedtop{\lineheight-1pt}
1819 \begin{tikzpicture}[overlay, yscale=-1]
1820 \tikzstyle{overlaybox}=[fill=lightgray,opacity=0.2]
1823 \draw[overlaybox] (2*\charwidth,\mintedtop) rectangle
1824 +(16*\charwidth,\lineheight);
1827 \draw[overlaybox] (2*\charwidth,\mintedtop+\lineheight) rectangle
1828 +(16*\charwidth,\lineheight);
1831 \draw[overlaybox] (2*\charwidth,\mintedtop+2*\lineheight) rectangle
1832 +(16*\charwidth,\lineheight);
1834 \draw[overlaybox] (\indent-3*\charwidth,\mintedtop) rectangle
1835 +(18*\charwidth,2*\lineheight);
1837 \draw[overlaybox] (3*\charwidth,\mintedtop+\lineheight) rectangle
1838 +(14*\charwidth,2*\lineheight);
1841 \draw[overlaybox] (\indent,\mintedtop) rectangle
1842 +(12*\charwidth,3*\lineheight);
1844 % indent should be 5 spaces
1845 \begin{minted}[linenos,firstnumber=16]{java}
1850 \caption{Example of how the text selections generator would generate text
1851 selections based on a lists of statements. Each highlighted rectangle
1852 represents a text selection.}
1853 \label{lst:textSelectionsExample}
1856 Each nesting level of a method body can have many such sequences of statements.
1857 The outermost nesting level has one such sequence, and each branch contains
1858 its own sequence of statements. \Myref{lst:grandExample} has a version of some
1859 code where all such sequences of statements are highlighted for a method body.
1861 To complete our example of possible text selections, I will now list all
1862 possible text selections for the method in \myref{lst:grandExample}, by nesting
1863 level. There are 23 of them in total.
1866 \item[Level 1 (10 selections)] \hfill \\
1867 $\{(5,9), (11), (12), (14,21), (5,11), (5,12), (5,21), (11,12),
1868 (11,21), \\(12,21)\}$
1870 \item[Level 2 (13 selections)] \hfill \\
1871 $\{(6), (7), (8), (6,7), (6,8), (7,8), (16), (17), (18), (16,17), (16,18), \\
1875 \subsubsection{The complexity}\label{sec:complexity}
1876 The complexity of how many text selections that need to be analyzed for a body
1877 of in total $n$ statements, is bounded by $O(n^2)$. A body of statements is here
1878 all the statements in all nesting levels of a sequence of statements. A method
1879 body (or a block) is a body of statements. To prove that the complexity is
1880 bounded by $O(n^2)$, I present a couple of theorems and prove them.
1883 The number of text selections that need to be analyzed for each list of
1884 statements of length $n$, is exactly
1887 \sum_{i=1}^{n} i = \frac{n(n+1)}{2}
1888 \label{eq:complexityStatementList}
1890 \label{thm:numberOfTextSelection}
1894 For $n=1$ this is trivial: $\frac{1(1+1)}{2} = \frac{2}{2} = 1$. One statement
1895 equals one selection.
1897 For $n=2$, you get one text selection for the first statement, one selection
1898 for the second statement, and one selection for the two of them combined.
1899 This equals three selections. $\frac{2(2+1)}{2} = \frac{6}{2} = 3$.
1901 For $n=3$, you get 3 selections for the two first statements, as in the case
1902 where $n=2$. In addition you get one selection for the third statement itself,
1903 and two more statements for the combinations of it with the two previous
1904 statements. This equals six selections. $\frac{3(3+1)}{2} = \frac{12}{2} = 6$.
1906 Assume that for $n=k$ there exists $\frac{k(k+1)}{2}$ text selections. Then we
1907 want to add selections for another statement, following the previous $k$
1908 statements. So, for $n=k+1$, we get one additional selection for the statement
1909 itself. Then we get one selection for each pair of the new selection and the
1910 previous $k$ statements. So the total number of selections will be the number
1911 of already generated selections, plus $k$ for every pair, plus one for the
1912 statement itself: $\frac{k(k+1)}{2} + k +
1913 1 = \frac{k(k+1)+2k+2}{2} = \frac{k(k+1)+2(k+1)}{2} = \frac{(k+1)(k+2)}{2} =
1914 \frac{(k+1)((k+1)+1)}{2} = \sum_{i=1}^{k+1} i$
1917 %\definition{A \emph{body of statements} is a sequence of statements where every
1918 %statement may have sub-statements.}
1921 The number of text selections for a body of statements is maximized if all the
1922 statements are at the same level.
1923 \label{thm:textSelectionsMaximized}
1927 Assume we have a body of, in total, $k$ statements. Then, the sum of the
1928 lengths of all the lists of statements in the body, is also $k$. Let
1929 $\{l,\ldots,m,(k-l-\ldots-m)\}$ be the lengths of the lists of statements in
1930 the body, with $l+\ldots+m<k \Rightarrow \forall i \in \{l,\ldots,m\} : i < k$.
1932 Then, the number of text selections that are generated for the $k$ statements
1938 \frac{l(l+1)}{2} + \ldots + \frac{m(m+1)}{2} +
1939 \frac{(k-l-\ldots-m)((k-l-\ldots-m)+ 1)}{2} = \\
1940 \frac{l^2+l}{2} + \ldots + \frac{m^2+m}{2} + \frac{k^2 - 2kl - \ldots - 2km +
1941 l^2 + \ldots + m^2 + k - l - \ldots - m}{2} = \\
1942 \frac{2l^2 - 2kl + \ldots + 2m^2 - 2km + k^2 + k}{2}
1946 \noindent It then remains to show that this inequality holds:
1949 \frac{2l^2 - 2kl + \ldots + 2m^2 - 2km + k^2 + k}{2} < \frac{k(k+1)}{2} =
1953 \noindent By multiplication by $2$ on both sides, and by removing the equal
1957 2l^2 - 2kl + \ldots + 2m^2 - 2km < 0
1960 Since $\forall i \in \{l,\ldots,m\} : i < k$, we have that $\forall i \in
1961 \{l,\ldots,m\} : 2ki > 2i^2$, so all the pairs of parts on the form $2i^2-2ki$
1962 are negative. In sum, the inequality holds.
1966 Therefore, the complexity for the number of selections that need to be analyzed
1967 for a body of $n$ statements is $O\bigl(\frac{n(n+1)}{2}\bigr) = O(n^2)$.
1969 \section{Disqualifying a selection}
1970 Certain text selections would lead to broken code if used as input to the
1971 \ExtractAndMoveMethod refactoring. To avoid this, we have to check all text
1972 selections for such conditions before they are further analyzed. This section
1973 is therefore going to present some properties that make a selection unsuitable
1974 for our refactoring. When analyzing all these properties, it is assumed that the
1975 source code does not contain any compilation errors.
1977 \subsection{A call to a protected or package-private method}
1978 If a text selection contains a call to a protected or package-private method, it
1979 would not be safe to move it to another class. The reason for this, is that we
1980 cannot know if the called method is being overridden by some subclass of the
1981 \gloss{enclosingClass}, or not.
1983 Imagine that the protected method \method{foo} is declared in class \m{A},
1984 and overridden in class \m{B}. The method \method{foo} is called from within a
1985 selection done to a method in \m{A}. We want to extract and move this selection
1986 to another class. The method \method{foo} is not public, so the \MoveMethod
1987 refactoring must make it public, making the extracted method able to call it
1988 from the extracted method's new location. The problem is, that the now public
1989 method \method{foo} is overridden in a subclass, where it has a protected
1990 status. This makes the compiler complain that the subclass \m{B} is trying to
1991 reduce the visibility of a method declared in its superclass \m{A}. This is not
1992 allowed in Java, and for good reasons. It would make it possible to make a
1993 subclass that could not be a substitute for its superclass.
1995 The problem this check helps to avoid, is a little subtle. The problem does not
1996 arise in the class where the change is done, but in a class derived from it.
1997 This shows that classes acting as superclasses are especially fragile to
1998 introducing errors in the context of automated refactoring.
2000 This is also shown in bug\ldots \todoin{File Eclipse bug report}
2003 \subsection{A double class instance creation}
2004 The following is a problem caused solely by the underlying \MoveMethod
2005 refactoring. The problem occurs if two classes are instantiated such that the
2006 first constructor invocation is an argument to a second, and that the first
2007 constructor invocation takes an argument that is built up using a field. As an
2008 example, say that \var{name} is a field of the enclosing class, and we have the
2009 expression \code{new A(new B(name))}. If this expression is located in a
2010 selection that is moved to another class, \var{name} will be left untouched,
2011 instead of being prefixed with a variable of the same type as it is declared in.
2012 If \var{name} is the destination for the move, it is not replaced by
2013 \code{this}, or removed if it is a prefix to a member access
2014 (\code{name.member}), but it is still left by itself.
2016 Situations like this would lead to code that will not compile. Therefore, we
2017 have to avoid them by not allowing selections to contain such double class
2018 instance creations that also contain references to fields.
2020 \todoin{File Eclipse bug report}
2023 \subsection{Instantiation of non-static inner class}
2024 When a non-static inner class is instantiated, this must happen in the scope of
2025 its declaring class. This is because it must have access to the members of the
2026 declaring class. If the inner class is public, it is possible to instantiate it
2027 through an instance of its declaring class, but this is not handled by the
2028 underlying \MoveMethod refactoring.
2030 Performing a move on a method that instantiates a non-static inner class, will
2031 break the code if the instantiation is not handled properly. For this reason,
2032 selections that contain instantiations of non-static inner classes are deemed
2033 unsuitable for the \ExtractAndMoveMethod refactoring.
2035 \subsection{References to enclosing instances of the enclosing class}
2036 To ``reference an enclosing instance of the enclosing class'' is to reference
2037 another instance than the one for the immediately enclosing class. Imagine there
2038 is a (non-static) class \m{C} that is declared in the inner scope of another
2039 class. That class can again be nested inside a third class, and so on. Hence,
2040 the nested class \m{C} can have access to many enclosing instances of its
2041 innermost enclosing class. A selection in a method declared in class \m{C} is
2042 disqualified if it contains a statement that contains a reference to one or more
2043 instances of these enclosing classes of \m{C}.
2045 The problem with this, is that these references may not be valid if they are
2046 moved to another class. Theoretically, some situations could easily be solved by
2047 passing, to the moved method, a reference to the instance where the problematic
2048 referenced member is declared. This should work in the case where this member is
2049 publicly accessible. This is not done in the underlying \MoveMethod refactoring,
2050 so it cannot be allowed in the \ExtractAndMoveMethod refactoring either.
2052 \subsection{Inconsistent return statements}
2053 To verify that a text selection is consistent with respect to return statements,
2054 we must check that if a selection contains a return statement, then every
2055 possible execution path within the selection ends in either a return or a throw
2056 statement. This property is important regarding the \ExtractMethod refactoring.
2057 If it holds, it means that a method could be extracted from the selection, and a
2058 call to it could be substituted for the selection. If the method has a non-void
2059 return type, then a call to it would also be a valid return point for the
2060 calling method. If its return value is of the void type, then the \ExtractMethod
2061 refactoring will append an empty return statement to the back of the method
2062 call. Therefore, the analysis does not discriminate on either kind of return
2063 statements, with or without a return value.
2065 A \emph{throw} statement is accepted anywhere a return statement is required.
2066 This is because a throw statement causes an immediate exit from the current
2067 block, together with all outer blocks in its control flow that does not catch
2068 the thrown exception.
2070 We separate between explicit and implicit return statements. An \emph{explicit}
2071 return statement is formed by using the \code{return} keyword, while an
2072 \emph{implicit} return statement is a statement that is not formed using
2073 \code{return}, but must be the last statement of a method that can have any side
2074 effects. This can happen in methods with a void return type. An example is a
2075 statement that is inside one or more blocks. The last statement of a method
2076 could for instance be a synchronized statement, but the last statement that is
2077 executed in the method, and that can have any side effects, may be located
2078 inside the body of the synchronized statement.
2080 We can start the check for this property by looking at the last statement of a
2081 selection to see if it is a return statement (explicit or implicit) or a throw
2082 statement. If this is the case, then the property holds, assuming the selected
2083 code do not contain any compilation errors. All execution paths within the
2084 selection should end in either this, or another, return or throw statement.
2086 If the last statement of the selection is not a \emph{return} or \emph{throw},
2087 the execution of it must eventually end in one of these types of statements for
2088 the selection to be legal. This means that all branches of the last statement of
2089 every branch must end in a return or throw. Given this recursive definition,
2090 there are only five types of statements that are guaranteed to end in a return
2091 or throw if their child branches do. All other statements would have to be
2092 considered illegal. The first three: Block-statements, labeled statements and
2093 do-statements are all kinds of fall-through statements that always get their
2094 body executed. Do-statements would not make much sense if written such that they
2095 always end after the first round of execution of their body, but that is not our
2096 concern. The remaining two statements that can end in a return or throw are
2097 if-statements and try-statements.
2099 For an if-statement, the rule is that if its then-part does not contain any
2100 return or throw statements, this is considered illegal. If the then-part does
2101 contain a return or throw, the else-part is checked. If its else-part is
2102 non-existent, or it does not contain any return or throw statements, the
2103 statement is considered illegal. If an if-statement is not considered illegal,
2104 the bodies of its two parts must be checked.
2106 Try-statements are handled much the same way as if-statements. The body of a
2107 try-statement must contain a return or throw. The same applies to its catch
2108 clauses and finally body. \todoin{finally body?}
2110 \subsection{Ambiguous return values}
2111 The problem with ambiguous return values arises when a selection is chosen to be
2112 extracted into a new method, but if refactored it needs to return more than one
2113 value from that method.
2115 This problem occurs in two situations. The first situation arises when there is
2116 more than one local variable that is both assigned to within a selection and
2117 also referenced after the selection. The other situation occurs when there is
2118 only one such assignment, but the selection also contain return statements.
2120 Therefore we must examine the selection for assignments to local variables that
2121 are referenced after the text selection. Then we must verify that not more than
2122 one such reference is done, or zero if any return statements are found.
2124 \subsection{Illegal statements}
2125 An illegal statement may be a statement that is of a type that is never allowed,
2126 or it may be a statement of a type that is only allowed if certain conditions
2129 Any use of the \var{super} keyword is prohibited, since its meaning is altered
2130 when moving a method to another class.
2132 For a \emph{break} statement, there are two situations to consider: A break
2133 statement with or without a label. If the break statement has a label, it is
2134 checked that whole of the labeled statement is inside the selection. If the
2135 break statement does not have a label attached to it, it is checked that its
2136 innermost enclosing loop or switch statement also is inside the selection.
2138 The situation for a \emph{continue} statement is the same as for a break
2139 statement, except that it is not allowed inside switch statements.
2141 Regarding \emph{assignments}, two types of assignments are allowed: Assignments
2142 to non-final variables and assignments to array access. All other assignments
2143 are regarded illegal.
2145 \paragraph{Incompleteness.}\label{par:incompleteness} The list of illegal
2146 statements is not complete, and a lot of situations that can lead to compilation
2147 errors or behavior changes are not considered. It is not feasible to consider
2148 all such situations within the limits of this master's project, and maybe not
2149 outside of them either. The feasibility of this problem could be explored
2152 \section{Disqualifying selections from the
2153 example}\label{sec:disqualifyingExample}
2154 Among the selections we found for the code in \myref{lst:grandExample}, not many
2155 of them must be disqualified on the basis of containing something illegal. The
2156 only statement causing trouble is the break statement in line 18. None of the
2157 selections on nesting level 2 can contain this break statement, since the
2158 innermost switch statement is not inside any of these selections.
2160 This means that the text selections $(18)$, $(16,18)$ and $(17,18)$ can be
2161 excluded from further consideration, and we are left with the following
2165 \item[Level 1 (10 selections)] \hfill \\
2166 $\{(5,9), (11), (12), (14,21), (5,11), (5,12), (5,21), (11,12),
2167 (11,21), \\(12,21)\}$
2169 \item[Level 2 (10 selections)] \hfill \\
2170 $\{(6), (7), (8), (6,7), (6,8), (7,8), (16), (17), (16,17), (20)\}$
2173 \section{Finding a move target}
2174 In the analysis needed to perform the \ExtractAndMoveMethod refactoring
2175 automatically, the selection we choose is found among all the selections that
2176 have a possible move target. Therefore, the best possible move target must be
2177 found for all the candidate selections, so that we are able to sort out the
2178 selection that is best suited for the refactoring.
2180 To find the best move target for a specific text selection, we first need to
2181 find all the possible targets. Since the target must be a local variable or a
2182 field, we are basically looking for names within the selection; names that
2183 represents references to variables.
2185 The names we are looking for, we call prefixes. This is because we are not
2186 interested in names that occur in the middle of a dot-separated sequence of
2187 names. We are only interested in names constituting prefixes of other names, and
2188 possibly themselves. The reason for this, is that two lexically equal names need
2189 not be referencing the same variable, if they themselves are not referenced via
2190 the same prefix. Consider the two method calls \code{a.x.foo()} and
2191 \code{b.x.foo()}. Here, the two references to \code{x}, in the middle of the
2192 qualified names both preceding \code{foo()}, are not referencing the same
2193 variable. Even though the variables may share the type, and the method
2194 \method{foo} thus is the same for both, we would not know through which of the
2195 variables \var{a} or \var{b} we should call the extracted method.
2197 The possible move targets are then the prefixes that are not among a subset of
2198 the prefixes that are not valid move targets \see{sec:unfixes}. Also, prefixes
2199 that are just simple names, and have only one occurrence, are left out. This is
2200 because they are not going to have any positive effect on coupling between
2201 classes, and are only going to increase the complexity of the code.
2203 For finding the best move target among these safe prefixes, a simple heuristic
2204 is used. It is as simple as choosing the prefix that is most frequently
2205 referenced within the selection.
2207 \section{Unfixes}\label{sec:unfixes}
2208 We will call the prefixes that are not valid as move targets for unfixes.
2210 A name that is assigned to within a selection can be an unfix. The reason for
2211 this is that the result would be an assignment to the \type{this} keyword, which
2212 is not valid in Java \see{eclipse_bug_420726}.
2214 Prefixes that originate from variable declarations within the same selection are
2215 also considered unfixes. The reason for this is that when a method is moved, it
2216 needs to be called through a variable. If this variable is also declared within
2217 the method that is to be moved, this obviously cannot be done.
2219 Also considered as unfixes are variable references that are of types that are
2220 not suitable for moving methods to. This can either be because it is not
2221 physically possible to move a method to the desired class or that it will cause
2222 compilation errors by doing so.
2224 If the type binding for a name is not resolved it is considered an unfix. The
2225 same applies to types that are only found in compiled code, so they have no
2226 underlying source that is accessible to us. (E.g. the \type{java.lang.String}
2229 Interface types are not suitable as targets. This is simply because interfaces
2230 in Java cannot contain methods with bodies. (This thesis does not deal with
2231 features of Java versions later than Java 7. Java 8 has interfaces with default
2232 implementations of methods.)
2234 Neither are local types allowed. This accounts for both local and anonymous
2235 classes. Anonymous classes are effectively the same as interface types with
2236 respect to unfixes. Local classes could in theory be used as targets, but this
2237 is not possible due to limitations of the way the \refa{Extract and Move Method}
2238 refactoring has to be implemented. The problem is that the refactoring is done
2239 in two steps, so the intermediate state between the two refactorings would not
2240 be legal Java code. In the intermediate step for the case where a local class is
2241 the move target, the extracted method would need to take the local class as a
2242 parameter. This new method would need to live in the scope of the declaring
2243 class of the originating method. The local class would then not be in the scope
2244 of the extracted method, thus bringing the source code into an illegal state.
2245 This scenario is shown in \myref{lst:extractMethodLocalClass}. One could imagine
2246 that the method was extracted and moved in one operation, without an
2247 intermediate state. Then it would make sense to include variables with types of
2248 local classes in the set of legal targets, since the local classes would then be
2249 in the scopes of the method calls. If this makes any difference for software
2250 metrics that measure coupling would be a different discussion.
2252 \begin{listing}[htb]
2253 \def\charwidth{5.8pt}
2254 \def\indent{2*\charwidth}
2255 \def\rightColX{32*\charwidth-1pt}
2256 \def\lineheight{\baselineskip}
2257 \def\mintedtop{2*\lineheight+5.8pt}
2259 \begin{tikzpicture}[overlay, yscale=-1]
2260 \tikzstyle{overlaybox}=[fill=lightgray,opacity=0.2]
2262 \draw[overlaybox] (0,\mintedtop+\lineheight*8) rectangle
2263 +(27*\charwidth,2*\lineheight);
2266 \draw[overlaybox] (\rightColX,\mintedtop+\lineheight*8) rectangle
2267 +(27*\charwidth,\lineheight);
2269 \draw[overlaybox] (\rightColX,\mintedtop+\lineheight*12) rectangle
2270 +(30*\charwidth,4*\lineheight);
2273 \begin{multicols}{2}
2274 \begin{minted}[frame=topline,label=Before,framesep=\mintedframesep]{java}
2275 void declaresLocalClass() {
2290 \begin{minted}[frame=topline,label={After Extract
2291 Method},framesep=\mintedframesep]{java}
2292 void declaresLocalClass() {
2303 // Illegal intermediate step
2304 void fooBar(LocalClass inst) {
2310 \caption{The \refa{Extract and Move Method} refactoring bringing the code into
2311 an illegal state with an intermediate step.}
2312 \label{lst:extractMethodLocalClass}
2315 The last class of names that are considered unfixes are names used in null
2316 tests. These are tests that read like this: if \code{<name>} equals \var{null}
2317 then do something. If allowing variables used in those kinds of expressions as
2318 targets for moving methods, we would end up with code containing boolean
2319 expressions like \code{this == null}, which would always evaluate to
2320 \code{false}, since \var{this} would never be \var{null}. The existence of a
2321 null test indicates that a variable is expected to sometimes hold the value
2322 \var{null}. By using a variable used in a null test as a move target, we could
2323 potentially end up with a
2324 null pointer exception if the method is called on a variable with a null value.
2326 \section{Finding the example selections that have possible targets}
2327 We now pick up the thread from \myref{sec:disqualifyingExample} where we have a
2328 set of text selections that need to be analyzed to find out if some of them are
2329 suitable targets for the \ExtractAndMoveMethod refactoring.
2331 We start by analyzing the text selections for nesting level 2, because these
2332 results can be used to reason about the selections for nesting level 1. First we
2333 have all the single-statement selections.
2336 \item[Selections $(6)$, $(8)$ and $(20)$.] \hfill \\
2337 All these selections have a prefix that contains a possible target, namely
2338 the variable \var{a}. The problem is that the prefixes are only one segment
2339 long, and their frequency counts are only 1 as well. None of these
2340 selections are therefore considered as suitable candidates for the
2343 \item[Selection $(7)$.] \hfill \\
2344 This selection contains the unfix \var{a}, and no other possible targets.
2345 The reason for \var{a} being an unfix is that it is assigned to within the
2346 selection. Selection $(7)$ is therefore unsuited as a refactoring candidate.
2348 \item[Selections $(16)$ and $(17)$.] \hfill \\
2349 These selections both have a possible target. The target for both selections
2350 is the variable \var{b}. Both the prefixes have frequency 1. We denote this
2351 with the new tuples $((16), \texttt{b.a}, f(1))$ and $((17), \texttt{b.a},
2352 f(1))$. They contain the selection, the prefix with the target and the
2353 frequency for this prefix.
2357 Then we have all the text selections from level 2 that are composed of multiple
2361 \item[Selections $(6,7)$, $(6,8)$ and $(7,8)$.] \hfill \\
2362 All these selections are disqualified for the reason that they contain the
2363 unfix \var{a}, due to the assignment, and no other possible move targets.
2365 \item[Selection $(16,17)$.] \hfill \\
2366 This selection is the last selection that is not analyzed on nesting level
2367 2. It contains only one possible move target, and that is the variable
2368 \var{b}. It also contains only one prefix \var{b.a}, with frequency count
2369 2. Therefore we have a new candidate $((16,17), \texttt{b.a}, f(2))$.
2373 Moving on to the text selections for nesting level 1, starting with the
2374 single-statement selections:
2377 \item[Selection $(5,9)$.] \hfill \\
2378 This selection contains two variable references that must be analyzed to see
2379 if they are possible move candidates. The first one is the variable
2380 \var{bool}. This variable is of type \type{boolean}, which is a primary type
2381 and therefore not possible to make any changes to. The second variable is
2382 \var{a}. The variable \var{a} is an unfix in $(5,9)$, for the same reason as
2383 in the selections $(6,7)$, $(7,8)$ and $(6,8)$. So selection $(5,9)$
2384 contains no possible move targets.
2386 \item[Selections $(11)$ and $(12)$.] \hfill \\
2387 These selections are disqualified for the same reasons as selections $(6)$
2388 and $(8)$. Their prefixes are one segment long and are referenced only one
2391 \item[Selection $(14,21)$] \hfill \\
2392 This is the switch statement from \myref{lst:grandExample}. It contains the
2393 relevant variable references \var{val}, \var{a} and \var{b}. The variable
2394 \var{val} is a primary type, just as \var{bool}. The variable \var{a} is
2395 only found in one statement, and in a prefix with only one segment, so it is
2396 not considered to be a possible move target. The only variable left is
2397 \var{b}. Just as in the selection $(16,17)$, \var{b} is part of the prefix
2398 \code{b.a}, which has 2 appearances. We have found a new candidate
2399 $((14,21), \texttt{b.a}, f(2))$.
2403 It remains to see if we get any new candidates by analyzing the multi-statement
2404 text selections for nesting level 1:
2407 \item[Selections $(5,11)$ and $(5,12)$.] \hfill \\
2408 These selections are disqualified for the same reason as $(5,9)$. The only
2409 possible move target \var{a} is an unfix.
2411 \item[Selection $(5,21)$.] \hfill \\
2412 This is whole of the method body in \myref{lst:grandExample}. The variables
2413 \var{a}, \var{bool} and \var{val} are either an unfix or primary types. The
2414 variable \var{b} is the only possible move target, and we have, again, the
2415 prefix \code{b.a} as the center of attention. The refactoring candidate is
2416 $((5,21), \texttt{b.a}, f(2))$.
2418 \item[Selection $(11,12)$.] \hfill \\
2419 This small selection contains the prefix \code{a} with frequency 2, and no
2420 unfixes. The candidate is $((11,12), \texttt{a}, f(2))$.
2422 \item[Selection $(11,21)$] \hfill \\
2423 This selection contains the selection $(11,12)$ in addition to the switch
2424 statement. The selection has two possible move targets. The first one is
2425 \var{b}, in a prefix with frequency 2. The second is \var{a}, although it
2426 is in a simple prefix, it is referenced 3 times, and is therefore chosen
2427 as the target for the selection. The new candidate is $((11,21),
2430 \item[Selection $(12,21)$.] \hfill \\
2431 This selection is similar to the previous $(11,21)$, only that \var{a} now
2432 has frequency count 2. This means that the prefixes \code{a} and
2433 \code{b.a} both have the count 2. Of the two, \code{b.a} is preferred,
2434 since it has more segments than \code{a}. Thus the candidate for this
2435 selection is $((12,21), \texttt{b.a}, f(2))$.
2439 For the method in \myref{lst:grandExample} we therefore have the following 8
2440 candidates for the \ExtractAndMoveMethod refactoring: $\{((16), \texttt{b.a},
2441 f(1)), ((17), \texttt{b.a}, f(1)), ((16,17), \texttt{b.a}, f(2)), ((14,21),
2442 \texttt{b.a}, f(2)), \\ ((5,21), \texttt{b.a}, f(2)), ((11,12), \texttt{a},
2443 f(2)), ((11,21), \texttt{a}, f(3)), ((12,21), \texttt{b.a}, f(2))\}$.
2445 It now only remains to specify an order for these candidates, so we can choose
2446 the most suitable one to refactor.
2449 \section{Choosing the selection}\label{sec:choosingSelection}
2450 When choosing a selection between the text selections that have possible move
2451 targets, the selections need to be ordered. The criteria below are presented in
2452 the order they are prioritized. If not one selection is favored over the other
2453 for a concrete criterion, the selections are evaluated by the next criterion.
2456 \item The first criterion that is evaluated is whether a selection contains
2457 any unfixes or not. If selection \m{A} contains no unfixes, while selection
2458 \m{B} does, selection \m{A} is favored over selection \m{B}. This is
2459 because, if we can, we want to avoid moving such as assignments and variable
2460 declarations. This is done under the assumption that, if possible, avoiding
2461 selections containing unfixes will make the code moved a little cleaner.
2463 \item The second criterion that is evaluated is whether a selection contains
2464 multiple possible targets or not. If selection \m{A} has only one possible
2465 target, and selection \m{B} has multiple, selection \m{A} is favored. If
2466 both selections have multiple possible targets, they are considered equal
2467 with respect to this criterion. The rationale for this heuristic is that we
2468 would prefer not to introduce new couplings between classes when performing
2469 the \ExtractAndMoveMethod refactoring.
2471 \item When evaluating this criterion, this is with the knowledge that
2472 selection \m{A} and \m{B} both have one possible target, or multiple
2473 possible targets. Then, if the move target candidate of selection \m{A} has
2474 a higher reference count than the target candidate of selection \m{B},
2475 selection \m{A} is favored. The reason for this is that we would like to
2476 move the selection that gets rid of the most references to another class.
2478 \item The last criterion is that if the frequencies of the targets chosen for
2479 both selections are equal, the selection with the target that is part of the
2480 prefix with highest number of segments is favored. This is done to favor
2485 If none of the above mentioned criteria favor one selection over another, the
2486 selections are considered to be equally good candidates for the
2487 \ExtractAndMoveMethod refactoring.
2489 \section{Performing changes}
2490 When a text selection and a move target is found for the \ExtractAndMoveMethod
2491 refactoring, the actual changes are executed by two existing primitive
2492 refactorings. First the \ExtractMethod refactoring is used to extract the
2493 selection into a new method. Then the \MoveMethod refactoring is used to move
2494 that new method to the class determined by the move target.
2496 If, at any point, an exception is thrown or the preconditions for one of the
2497 primitive refactorings are not satisfied, the composite refactoring is aborted,
2498 and the source code is left in its current state. This has the implication that
2499 the \ExtractAndMoveMethod refactoring could end up being partially executed.
2500 This happens if the \ExtractMethod refactoring is executed, but the \MoveMethod
2501 refactoring is being canceled. A partial execution is not considered a problem,
2502 since the code should still compile.
2504 \section{Concluding the example}
2505 For choosing one of the remaining selections, we need to order our candidates
2506 after the criteria in the previous section. Below we have the candidates ordered
2507 in descending order, with the ``best'' candidate first:
2509 \begin{multicols}{2}
2511 \item $((16,17), \texttt{b.a}, f(2))$
2512 \item $((11,12), \texttt{a}, f(2))$
2513 \item $((16), \texttt{b.a}, f(1))$
2514 \item $((17), \texttt{b.a}, f(1))$
2517 % Many possible targets
2518 \item $((11,21), \texttt{a}, f(3))$
2519 \item $((5,21), \texttt{b.a}, f(2))$
2520 \item $((12,21), \texttt{b.a}, f(2))$
2521 \item $((14,21), \texttt{b.a}, f(2))$
2546 The candidates ordered 5-8 all have unfixes in them, therefore they are ordered
2547 last. None of the candidates ordered 1-4 have multiple possible targets. The
2548 only interesting discussion is now why $(16,17)$ was favored over $(11,12)$.
2549 This is because the prefix \code{b.a} enclosing the move target of selection
2550 $(16,17)$ has one more segment than the prefix \code{a} of $(11,12)$.
2552 The selection is now extracted into a new method \method{gen\_123} and then
2553 moved to class \type{B}, since that is the type of the variable \var{b} that is
2554 the target from the chosen refactoring candidate. The name of the method has a
2555 randomly generated suffix. In the refactoring implementation, the extracted
2556 methods follow the pattern \code{generated\_<long>}, where \code{<long>} is a
2557 pseudo-random long value. This is shortened here to make the example readable.
2558 The result after the refactoring is shown in \myref{lst:grandExampleResult}.
2560 \begin{listing}[htb]
2561 \def\charwidth{5.8pt}
2562 \def\indent{2*\charwidth}
2563 \def\rightColX{32*\charwidth-1pt}
2564 \def\lineheight{\baselineskip}
2565 \def\mintedtop{1*\lineheight+1.8pt}
2567 \begin{tikzpicture}[overlay, yscale=-1]
2568 \tikzstyle{overlaybox}=[fill=lightgray,opacity=0.2]
2570 \draw[overlaybox] (2*\indent,\mintedtop+\lineheight*15) rectangle
2571 +(18*\charwidth,\lineheight);
2574 \draw[overlaybox] (\rightColX,\mintedtop+\lineheight*3) rectangle
2575 +(29*\charwidth,4*\lineheight);
2578 \begin{multicols}{2}
2579 \begin{minted}[linenos]{java}
2581 A a; B b; boolean bool;
2583 void method(int val) {
2606 \begin{minted}[]{java}
2610 public void gen_123(C c) {
2618 \caption{The result after refactoring the class \type{C} of
2619 \myref{lst:grandExample} with the \ExtractAndMoveMethod refactoring with
2620 $((16,17), \texttt{b.a}, f(2))$ as input.}
2621 \label{lst:grandExampleResult}
2624 \paragraph{Implementation details.} Implementation details for the various parts
2625 of this chapter are found in \myref{ch:implementation}.
2628 \chapter{The Eclipse Platform with the Java development tools}\label{ch:eclipse}
2629 The Eclipse Platform is an extensible platform. It can be used to build IDEs for
2630 many programming languages. For it to be a fully functional Java IDE, it must be
2631 equipped with the Java development tools plugin, abbreviated as JDT.
2633 This chapter will present how to analyze and change Java source code by
2634 utilizing the APIs supplied by Eclipse and the JDT.
2636 \section{Analyzing source code in Eclipse}
2637 In this section we will see how to access Java source code in the Eclipse
2638 workspace. Then it is shown how this code is being represented when it is parsed
2639 and how to search this representation for the properties we are after.
2641 \subsection{The Java model}\label{javaModel}
2642 The Java model of \name{Eclipse} is its internal representation of a Java project. It
2643 is light-weight, and has only limited possibilities for manipulating source
2644 code. It is typically used as a basis for the Package Explorer in \name{Eclipse}.
2646 The elements of the Java model are only handles to the underlying elements. This
2647 means that the underlying element of a handle does not need to actually exist.
2648 Hence the user of a handle must always check that it exist by calling the
2649 \method{exists} method of the handle.
2651 The handles with descriptions are listed in \myref{tab:javaModel}, while the
2652 hierarchy of the Java Model is shown in \myref{fig:javaModel}.
2655 \caption{The elements of the Java Model\citing{vogelEclipseJDT2012}.}
2656 \label{tab:javaModel}
2658 % sum must equal number of columns (3)
2659 \begin{tabularx}{\textwidth}{@{} L{0.7} L{1.1} L{1.2} @{}}
2661 \textbf{Project Element} & \textbf{Java Model element} &
2662 \textbf{Description} \\
2664 Java project & \type{IJavaProject} & The Java project which contains all other objects. \\
2666 Source folder /\linebreak[2] binary folder /\linebreak[3] external library &
2667 \type{IPackageFragmentRoot} & Hold source or binary files, can be a folder
2668 or a library (zip / jar file). \\
2670 Each package & \type{IPackageFragment} & Each package is below the
2671 \type{IPackageFragmentRoot}, sub-packages are not leaves of the package,
2672 they are listed directed under \type{IPackageFragmentRoot}. \\
2674 Java Source file & \type{ICompilationUnit} & The Source file is always below
2675 the package node. \\
2677 Types / Fields /\linebreak[3] Methods & \type{IType} / \type{IField}
2678 /\linebreak[3] \type{IMethod} & Types, fields and methods. \\
2686 \begin{tikzpicture}[%
2687 grow via three points={one child at (0,-0.7) and
2688 two children at (0,-0.7) and (0,-1.4)},
2689 edge from parent path={(\tikzparentnode.south west)+(0.5,0) |-
2690 (\tikzchildnode.west)}]
2691 \tikzstyle{every node}=[draw=black,thick,anchor=west]
2692 \tikzstyle{selected}=[draw=red,fill=red!30]
2693 \tikzstyle{optional}=[dashed,fill=gray!50]
2694 \node {\type{IJavaProject}}
2695 child { node {\type{IPackageFragmentRoot}}
2696 child { node {\type{IPackageFragment}}
2697 child { node {\type{ICompilationUnit}}
2698 child { node {\type{IType}}
2699 child { node {\type{\{ IType \}*}}
2700 child { node {\type{\ldots}}}
2703 child { node {\type{\{ IField \}*}}}
2704 child { node {\type{IMethod}}
2705 child { node {\type{\{ IType \}*}}
2706 child { node {\type{\ldots}}}
2711 child { node {\type{\{ IMethod \}*}}}
2720 child { node {\type{\{ IType \}*}}}
2731 child { node {\type{\{ ICompilationUnit \}*}}}
2744 child { node {\type{\{ IPackageFragment \}*}}}
2759 child { node {\type{\{ IPackageFragmentRoot \}*}}}
2762 \caption{The Java model of \name{Eclipse}. ``\type{\{ SomeElement \}*}'' means
2763 ``\type{SomeElement} zero or more times``. For recursive structures,
2764 ``\type{\ldots}'' is used.}
2765 \label{fig:javaModel}
2768 \subsection{The abstract syntax tree}
2769 \name{Eclipse} is following the common paradigm of using an abstract syntax tree for
2770 source code analysis and manipulation.
2772 When parsing program source code into something that can be used as a foundation
2773 for analysis, the start of the process follows the same steps as in a compiler.
2774 This is all natural, because the way a compiler analyzes code is no different
2775 from how source manipulation programs would do it, except for some properties of
2776 code that is analyzed in the parser, and that they may be differing in what
2777 kinds of properties they analyze. Thus the process of translation source code
2778 into a structure that is suitable for analyzing, can be seen as a kind of
2779 interrupted compilation process \see{fig:interruptedCompilationProcess}.
2784 base/.style={anchor=north, align=center, rectangle, minimum height=1.4cm},
2785 basewithshadow/.style={base, drop shadow, fill=white},
2786 outlined/.style={basewithshadow, draw, rounded corners, minimum
2788 primary/.style={outlined, font=\bfseries},
2789 dashedbox/.style={outlined, dashed},
2790 arrowpath/.style={black, align=center, font=\small},
2791 processarrow/.style={arrowpath, ->, >=angle 90, shorten >=1pt},
2793 \begin{tikzpicture}[node distance=1.3cm and 3cm, scale=1, every
2794 node/.style={transform shape}]
2795 \node[base](AuxNode1){\small source code};
2796 \node[primary, right=of AuxNode1, xshift=-2.5cm](Scanner){Scanner};
2797 \node[primary, right=of Scanner, xshift=0.5cm](Parser){Parser};
2798 \node[dashedbox, below=of Parser](SemanticAnalyzer){Semantic\\Analyzer};
2799 \node[dashedbox, left=of SemanticAnalyzer](SourceCodeOptimizer){Source
2801 \node[dashedbox, below=of SourceCodeOptimizer
2802 ](CodeGenerator){Code\\Generator};
2803 \node[dashedbox, right=of CodeGenerator](TargetCodeOptimizer){Target
2805 \node[base, right=of TargetCodeOptimizer](AuxNode2){};
2807 \draw[processarrow](AuxNode1) -- (Scanner);
2809 \path[arrowpath] (Scanner) -- node [sloped](tokens){tokens}(Parser);
2810 \draw[processarrow](Scanner) -- (tokens) -- (Parser);
2812 \path[arrowpath] (Parser) -- node (syntax){syntax
2813 tree}(SemanticAnalyzer);
2814 \draw[processarrow](Parser) -- (syntax) -- (SemanticAnalyzer);
2816 \path[arrowpath] (SemanticAnalyzer) -- node
2817 [sloped](annotated){annotated\\tree}(SourceCodeOptimizer);
2818 \draw[processarrow, dashed](SemanticAnalyzer) -- (annotated) --
2819 (SourceCodeOptimizer);
2821 \path[arrowpath] (SourceCodeOptimizer) -- node
2822 (intermediate){intermediate code}(CodeGenerator);
2823 \draw[processarrow, dashed](SourceCodeOptimizer) -- (intermediate) --
2826 \path[arrowpath] (CodeGenerator) -- node [sloped](target1){target
2827 code}(TargetCodeOptimizer);
2828 \draw[processarrow, dashed](CodeGenerator) -- (target1) --
2829 (TargetCodeOptimizer);
2831 \path[arrowpath](TargetCodeOptimizer) -- node [sloped](target2){target
2833 \draw[processarrow, dashed](TargetCodeOptimizer) -- (target2) (AuxNode2);
2835 \caption{Interrupted compilation process. {\footnotesize (Full compilation
2836 process borrowed from \emph{Compiler construction: principles and practice}
2837 by Kenneth C. Louden\citing{louden1997}.)}}
2838 \label{fig:interruptedCompilationProcess}
2841 The process starts with a \emph{scanner}, or lexer. The job of the scanner is to
2842 read the source code and divide it into tokens for the parser. Therefore, it is
2843 also sometimes called a tokenizer. A token is a logical unit, defined in the
2844 language specification, consisting of one or more consecutive characters. In
2845 the Java language the tokens can for instance be the \var{this} keyword, a curly
2846 bracket \var{\{} or a \var{nameToken}. It is recognized by the scanner on the
2847 basis of something equivalent of a regular expression. This part of the process
2848 is often implemented with the use of a finite automata. In fact, it is common to
2849 specify the tokens in regular expressions, which in turn are translated into a
2850 finite automata lexer. This process can be automated.
2852 The program component used to translate a stream of tokens into something
2853 meaningful, is called a parser. A parser is fed tokens from the scanner and
2854 performs an analysis of the structure of a program. It verifies that the syntax
2855 is correct according to the grammar rules of a language, that are usually
2856 specified in a context-free grammar, and often in a variant of the
2857 \name{Backus--Naur Form}. The result coming from the parser is in the form of an
2858 \emph{Abstract Syntax Tree}, AST for short. It is called \emph{abstract},
2859 because the structure does not contain all of the tokens produced by the
2860 scanner. It only contains logical constructs, and because it forms a tree, all
2861 kinds of parentheses and brackets are implicit in the structure. It is this AST
2862 that is used when performing the semantic analysis of the code.
2864 As an example we can think of the expression \code{(5 + 7) * 2}. The root of
2865 this tree would in \name{Eclipse} be an \type{InfixExpression} with the operator
2866 \var{TIMES}, and a left operand, which is also an \type{InfixExpression} with
2867 the operator \var{PLUS}. The left operand \type{InfixExpression}, has in turn a
2868 left operand of type \type{NumberLiteral} with the value \var{``5''} and a right
2869 operand \type{NumberLiteral} with the value \var{``7''}. The root will have a
2870 right operand of type \type{NumberLiteral} and value \var{``2''}. The AST for
2871 this expression is illustrated in \myref{fig:astInfixExpression}.
2873 Contrary to the Java Model, an abstract syntax tree is a heavy-weight
2874 representation of source code. It contains information about properties like
2875 type bindings for variables and variable bindings for names.
2880 \begin{tikzpicture}[scale=0.8]
2881 \tikzset{level distance=40pt}
2882 \tikzset{sibling distance=5pt}
2883 \tikzstyle{thescale}=[scale=0.8]
2884 \tikzset{every tree node/.style={align=center}}
2885 \tikzset{edge from parent/.append style={thick}}
2886 \tikzstyle{inode}=[rectangle,rounded corners,draw,fill=lightgray,drop
2887 shadow,align=center]
2888 \tikzset{every internal node/.style={inode}}
2889 \tikzset{every leaf node/.style={draw=none,fill=none}}
2891 \Tree [.\type{InfixExpression} [.\type{InfixExpression}
2892 [.\type{NumberLiteral} \var{``5''} ] [.\type{Operator} \var{PLUS} ]
2893 [.\type{NumberLiteral} \var{``7''} ] ]
2894 [.\type{Operator} \var{TIMES} ]
2895 [.\type{NumberLiteral} \var{``2''} ]
2898 \caption{The abstract syntax tree for the expression \code{(5 + 7) * 2}.}
2899 \label{fig:astInfixExpression}
2902 \subsubsection{The AST in Eclipse}\label{astEclipse}
2903 In \name{Eclipse}, every node in the AST is a child of the abstract superclass
2904 \typewithref{org.eclipse.jdt.core.dom}{ASTNode}. Every \type{ASTNode}, among a
2905 lot of other things, provides information about its position and length in the
2906 source code, as well as a reference to its parent and to the root of the tree.
2908 The root of the AST is always of type \type{CompilationUnit}. It is not the same
2909 as an instance of an \type{ICompilationUnit}, which is the compilation unit
2910 handle of the Java model. The children of a \type{CompilationUnit} is an
2911 optional \type{PackageDeclaration}, zero or more nodes of type
2912 \type{ImportDecaration} and all its top-level type declarations that has node
2913 types \type{AbstractTypeDeclaration}.
2915 An \type{AbstractType\-Declaration} can be one of the types
2916 \type{AnnotationType\-Declaration}, \type{Enum\-Declaration} or
2917 \type{Type\-Declaration}. The children of an \type{AbstractType\-Declaration}
2918 must be a subtype of a \type{BodyDeclaration}. These subtypes are:
2919 \type{AnnotationTypeMember\-Declaration}, \type{EnumConstant\-Declaration},
2920 \type{Field\-Declaration}, \type{Initializer} and \type{Method\-Declaration}.
2922 Of the body declarations, the \type{Method\-Declaration} is the most interesting
2923 one. Its children include lists of modifiers, type parameters, parameters and
2924 exceptions. It has a return type node and a body node. The body, if present, is
2925 of type \type{Block}. A \type{Block} is itself a \type{Statement}, and its
2926 children is a list of \type{Statement} nodes.
2928 There are too many types of the abstract type \type{Statement} to list up, but
2929 there exists a subtype of \type{Statement} for every statement type of Java, as
2930 one would expect. This also applies to the abstract type \type{Expression}.
2931 However, the expression \type{Name} is a little special, since it is both used
2932 as an operand in compound expressions, as well as for names in type declarations
2935 There is an overview of some of the structure of an \name{Eclipse} AST in
2936 \myref{fig:astEclipse}.
2940 \begin{tikzpicture}[scale=0.8]
2941 \tikzset{level distance=50pt}
2942 \tikzset{sibling distance=5pt}
2943 \tikzstyle{thescale}=[scale=0.8]
2944 \tikzset{every tree node/.style={align=center}}
2945 \tikzset{edge from parent/.append style={thick}}
2946 \tikzstyle{inode}=[rectangle,rounded corners,draw,fill=lightgray,drop
2947 shadow,align=center]
2948 \tikzset{every internal node/.style={inode}}
2949 \tikzset{every leaf node/.style={draw=none,fill=none}}
2951 \Tree [.\type{CompilationUnit} [.\type{[ PackageDeclaration ]} [.\type{Name} ]
2952 [.\type{\{ Annotation \}*} ] ]
2953 [.\type{\{ ImportDeclaration \}*} [.\type{Name} ] ]
2954 [.\type{\{ AbstractTypeDeclaration \}+} [.\node(site){\type{\{
2955 BodyDeclaration \}*}}; ] [.\type{SimpleName} ] ]
2957 \begin{scope}[shift={(0.5,-6)}]
2958 \node[inode,thescale](root){\type{MethodDeclaration}};
2959 \node[inode,thescale](modifiers) at (4.5,-5){\type{\{ IExtendedModifier \}*}
2960 \\ {\footnotesize (Of type \type{Modifier} or \type{Annotation})}};
2961 \node[inode,thescale](typeParameters) at (-6,-3.5){\type{\{ TypeParameter
2963 \node[inode,thescale](parameters) at (-5,-5){\type{\{
2964 SingleVariableDeclaration \}*} \\ {\footnotesize (Parameters)}};
2965 \node[inode,thescale](exceptions) at (5,-3){\type{\{ Name \}*} \\
2966 {\footnotesize (Exceptions)}};
2967 \node[inode,thescale](return) at (-6.5,-2){\type{Type} \\ {\footnotesize
2969 \begin{scope}[shift={(0,-5)}]
2970 \Tree [.\node(body){\type{[ Block ]} \\ {\footnotesize (Body)}};
2971 [.\type{\{ Statement \}*} [.\type{\{ Expression \}*} ]
2972 [.\type{\{ Statement \}*} [.\type{\ldots} ]]
2977 \draw[->,>=triangle 90,shorten >=1pt](root.east)..controls +(east:2) and
2978 +(south:1)..(site.south);
2980 \draw (root.south) -- (modifiers);
2981 \draw (root.south) -- (typeParameters);
2982 \draw (root.south) -- ($ (parameters.north) + (2,0) $);
2983 \draw (root.south) -- (exceptions);
2984 \draw (root.south) -- (return);
2985 \draw (root.south) -- (body);
2988 \caption{The format of the abstract syntax tree in \name{Eclipse}.}
2989 \label{fig:astEclipse}
2992 \subsection{The ASTVisitor}\label{astVisitor}
2993 So far, the only thing that has been addressed is how the data that is going to
2994 be the basis for our analysis is structured. Another aspect of it is how we are
2995 going to traverse the AST to gather the information we need, so we can conclude
2996 about the properties we are analyzing. It is of course possible to start at the
2997 top of the tree, and manually search through its nodes for the ones we are
2998 looking for, but that is a bit inconvenient. To be able to efficiently utilize
2999 such an approach, we would need to make our own framework for traversing the
3000 tree and visiting only the types of nodes we are after. Luckily, this
3001 functionality is already provided in \name{Eclipse}, by its
3002 \typewithref{org.eclipse.jdt.core.dom}{ASTVisitor}.
3004 The \name{Eclipse} AST, together with its \type{ASTVisitor}, follows the
3005 \pattern{Visitor} pattern\citing{designPatterns}. The intent of this design
3006 pattern is to facilitate extending the functionality of classes without touching
3007 the classes themselves.
3009 Let us say that there is a class hierarchy of elements. These elements all have
3010 a method \method{accept(Visitor visitor)}. In its simplest form, the
3011 \method{accept} method just calls the \method{visit} method of the visitor with
3012 itself as an argument, like this: \code{visitor.visit(this)}. For the visitors
3013 to be able to extend the functionality of all the classes in the elements
3014 hierarchy, each \type{Visitor} must have one visit method for each concrete
3015 class in the hierarchy. Say the hierarchy consists of the concrete classes
3016 \type{ConcreteElementA} and \type{ConcreteElementB}. Then each visitor must have
3017 the (possibly empty) methods \method{visit(ConcreteElementA element)} and
3018 \method{visit(ConcreteElementB element)}. This scenario is depicted in
3019 \myref{fig:visitorPattern}.
3023 \tikzstyle{abstract}=[rectangle, draw=black, fill=white, drop shadow, text
3024 centered, anchor=north, text=black, text width=6cm, every one node
3025 part/.style={align=center, font=\bfseries\itshape}]
3026 \tikzstyle{concrete}=[rectangle, draw=black, fill=white, drop shadow, text
3027 centered, anchor=north, text=black, text width=6cm]
3028 \tikzstyle{inheritarrow}=[->, >=open triangle 90, thick]
3029 \tikzstyle{commentarrow}=[->, >=angle 90, dashed]
3030 \tikzstyle{line}=[-, thick]
3031 \tikzset{every one node part/.style={align=center, font=\bfseries}}
3032 \tikzset{every second node part/.style={align=center, font=\ttfamily}}
3034 \begin{tikzpicture}[node distance=1cm, scale=0.8, every node/.style={transform
3036 \node (Element) [abstract, rectangle split, rectangle split parts=2]
3038 \nodepart{one}{Element}
3039 \nodepart{second}{+accept(visitor: Visitor)}
3041 \node (AuxNode01) [text width=0, minimum height=2cm, below=of Element] {};
3042 \node (ConcreteElementA) [concrete, rectangle split, rectangle split
3043 parts=2, left=of AuxNode01]
3045 \nodepart{one}{ConcreteElementA}
3046 \nodepart{second}{+accept(visitor: Visitor)}
3048 \node (ConcreteElementB) [concrete, rectangle split, rectangle split
3049 parts=2, right=of AuxNode01]
3051 \nodepart{one}{ConcreteElementB}
3052 \nodepart{second}{+accept(visitor: Visitor)}
3055 \node[comment, below=of ConcreteElementA] (CommentA) {visitor.visit(this)};
3057 \node[comment, below=of ConcreteElementB] (CommentB) {visitor.visit(this)};
3059 \node (AuxNodeX) [text width=0, minimum height=1cm, below=of AuxNode01] {};
3061 \node (Visitor) [abstract, rectangle split, rectangle split parts=2,
3064 \nodepart{one}{Visitor}
3065 \nodepart{second}{+visit(ConcreteElementA)\\+visit(ConcreteElementB)}
3067 \node (AuxNode02) [text width=0, minimum height=2cm, below=of Visitor] {};
3068 \node (ConcreteVisitor1) [concrete, rectangle split, rectangle split
3069 parts=2, left=of AuxNode02]
3071 \nodepart{one}{ConcreteVisitor1}
3072 \nodepart{second}{+visit(ConcreteElementA)\\+visit(ConcreteElementB)}
3074 \node (ConcreteVisitor2) [concrete, rectangle split, rectangle split
3075 parts=2, right=of AuxNode02]
3077 \nodepart{one}{ConcreteVisitor2}
3078 \nodepart{second}{+visit(ConcreteElementA)\\+visit(ConcreteElementB)}
3082 \draw[inheritarrow] (ConcreteElementA.north) -- ++(0,0.7) -|
3084 \draw[line] (ConcreteElementA.north) -- ++(0,0.7) -|
3085 (ConcreteElementB.north);
3087 \draw[inheritarrow] (ConcreteVisitor1.north) -- ++(0,0.7) -|
3089 \draw[line] (ConcreteVisitor1.north) -- ++(0,0.7) -|
3090 (ConcreteVisitor2.north);
3092 \draw[commentarrow] (CommentA.north) -- (ConcreteElementA.south);
3093 \draw[commentarrow] (CommentB.north) -- (ConcreteElementB.south);
3097 \caption{The Visitor Pattern.}
3098 \label{fig:visitorPattern}
3101 The use of the visitor pattern can be appropriate when the hierarchy of elements
3102 is mostly stable, but the family of operations over its elements is constantly
3103 growing. This is clearly the case for the \name{Eclipse} AST, since the
3104 hierarchy for the type \type{ASTNode} is very stable, but the functionality of
3105 its elements is extended every time someone need to operate on the AST. Another
3106 aspect of the \name{Eclipse} implementation is that it is a public API, and the
3107 visitor pattern is an easy way to provide access to the nodes in the tree.
3109 The version of the visitor pattern implemented for the AST nodes in \name{Eclipse} also
3110 provides an elegant way to traverse the tree. It does so by following the
3111 convention that every node in the tree first let the visitor visit itself,
3112 before it also makes all its children accept the visitor. The children are only
3113 visited if the visit method of their parent returns \var{true}. This pattern
3114 then makes for a prefix traversal of the AST. If postfix traversal is desired,
3115 the visitors also have \method{endVisit} methods for each node type, which is
3116 called after the \method{visit} method for a node. In addition to these visit
3117 methods, there are also the methods \method{preVisit(ASTNode)},
3118 \method{postVisit(ASTNode)} and \method{preVisit2(ASTNode)}. The
3119 \method{preVisit} method is called before the type-specific \method{visit}
3120 method. The \method{postVisit} method is called after the type-specific
3121 \method{endVisit}. The type specific \method{visit} is only called if
3122 \method{preVisit2} returns \var{true}. Overriding the \method{preVisit2} is also
3123 altering the behavior of \method{preVisit}, since the default implementation is
3124 responsible for calling it.
3126 An example of a trivial \type{ASTVisitor} is shown in
3127 \myref{lst:astVisitorExample}.
3130 \begin{minted}{java}
3131 public class CollectNamesVisitor extends ASTVisitor {
3132 Collection<Name> names = new LinkedList<Name>();
3135 public boolean visit(QualifiedName node) {
3141 public boolean visit(SimpleName node) {
3147 \caption{An \type{ASTVisitor} that visits all the names in a subtree and adds
3148 them to a collection, except those names that are children of any
3149 \type{QualifiedName}.}
3150 \label{lst:astVisitorExample}
3153 \section{The refactoring API of Eclipse}\label{ch:jdt_refactorings}
3154 This section will present the design behind the refactoring support in
3155 \name{Eclipse}, and the JDT in specific. After which it will follow a section
3156 about shortcomings of the refactoring API in terms of composition of
3160 The refactoring world of \name{Eclipse} can in general be separated into two parts: The
3161 language independent part and the part written for a specific programming
3162 language -- the language that is the target of the supported refactorings.
3164 \subsubsection{The Language Toolkit.}
3165 The Language Toolkit\footnote{The content of this section is a mixture of
3166 written material from
3167 \url{https://www.eclipse.org/articles/Article-LTK/ltk.html} and
3168 \url{http://www.eclipse.org/articles/article.php?file=Article-Unleashing-the-Power-of-Refactoring/index.html},
3169 the LTK source code and my own memory.}, or LTK for short, is the framework that
3170 is used to implement refactorings in \name{Eclipse}. It is language independent and
3171 provides the abstractions of a refactoring and the change it generates, in the
3172 form of the classes \typewithref{org.eclipse.ltk.core.refactoring}{Refactoring}
3173 and \typewithref{org.eclipse.ltk.core.refactoring}{Change}.
3175 There are also parts of the LTK that is concerned with user interaction, but
3176 they will not be discussed here, since they are of little value to us and our
3177 use of the framework. We are primarily interested in the parts that can be
3180 \paragraph{The Refactoring class.}
3181 The abstract class \type{Refactoring} is the core of the LTK framework. Every
3182 refactoring that is going to be supported by the LTK has to end up creating an
3183 instance of one of its subclasses. The main responsibilities of subclasses of
3184 \type{Refactoring} are to implement template methods for condition checking
3185 (\methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{checkInitialConditions}
3187 \methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{checkFinalConditions}),
3189 \methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{createChange}
3190 method that creates and returns an instance of the \type{Change} class.
3192 If the refactoring shall support that others participate in it when it is
3193 executed, the refactoring has to be a processor-based
3194 refactoring\typeref{org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring}.
3195 It then delegates to its given
3196 \typewithref{org.eclipse.ltk.core.refactoring.participants}{RefactoringProcessor}
3197 for condition checking and change creation. Participating in a refactoring can
3198 be useful in cases where the changes done to programming source code affect
3199 other related resources in the workspace. This can be names or paths in
3200 configuration files, or maybe one would like to perform additional logging of
3201 changes done in the workspace.
3203 \paragraph{The Change class.}
3204 This class is the base class for objects that is responsible for performing the
3205 actual workspace transformations in a refactoring. The main responsibilities for
3206 its subclasses are to implement the
3207 \methodwithref{org.eclipse.ltk.core.refactoring.Change}{perform} and
3208 \methodwithref{org.eclipse.ltk.core.refactoring.Change}{isValid} methods. The
3209 \method{isValid} method verifies that the change object is valid and thus can be
3210 executed by calling its \method{perform} method. The \method{perform} method
3211 performs the desired change and returns an undo change that can be executed to
3212 reverse the effect of the transformation done by its originating change object.
3214 \paragraph{Executing a refactoring}\label{executing_refactoring}
3215 The life cycle of a refactoring generally follows two steps after creation:
3216 condition checking and change creation. By letting the refactoring object be
3218 \typewithref{org.eclipse.ltk.core.refactoring}{CheckConditionsOperation} that
3219 in turn is handled by a
3220 \typewithref{org.eclipse.ltk.core.refactoring}{CreateChangeOperation}, it is
3221 assured that the change creation process is managed in a proper manner.
3223 The actual execution of a change object has to follow a detailed life cycle.
3224 This life cycle is honored if the \type{CreateChangeOperation} is handled by a
3225 \typewithref{org.eclipse.ltk.core.refactoring}{PerformChangeOperation}. If also
3226 an undo manager\typeref{org.eclipse.ltk.core.refactoring.IUndoManager} is set
3227 for the \type{PerformChangeOperation}, the undo change is added into the undo
3230 \subsubsection{The language specific refactorings}\label{sec:jdtRefactorings}
3231 The language specific refactorings supplied by the JDT that are relevant for
3232 this project are presented below. It is the JDT-implementations of the two
3233 primitive refactorings \ExtractMethod and \MoveMethod. In the JDT, the
3234 implementations of these refactorings are found in the classes
3235 \typewithref{org.eclipse.jdt.internal.corext.refactoring.code}{ExtractMethodRefactoring}
3237 \typewithref{org.eclipse.jdt.internal.corext.refactoring.structure}{MoveInstanceMethodProcessor},
3238 where the last class is designed to be used together with the processor-based
3239 \typewithref{org.eclipse.ltk.core.refactoring.participants}{MoveRefactoring}.
3241 \paragraph{The ExtractMethodRefactoring class.}
3242 This class is quite simple in its use. The only parameters it requires for
3243 construction is a compilation
3244 unit\typeref{org.eclipse.jdt.core.ICompilationUnit}, the offset into the source
3245 code where the extraction shall start, and the length of the source to be
3246 extracted. Then you have to set the method name for the new method together with
3247 its visibility and some not so interesting parameters.
3249 \paragraph{The MoveInstanceMethodProcessor class.}
3250 For the \refa{Move Method}, the processor requires a little more advanced input than
3251 the class for the \refa{Extract Method}. For construction it requires a method
3252 handle\typeref{org.eclipse.jdt.core.IMethod} for the method that is to be moved.
3253 Then the target for the move has to be supplied as the variable binding from a
3254 chosen variable declaration. In addition to this, some parameters have to be set
3255 regarding setters/getters, as well as delegation.
3257 To make the processor a working refactoring, a \type{MoveRefactoring} must be
3258 created with it as a parameter.
3261 \subsection{Shortcomings}
3262 This section is introduced naturally with a conclusion: The JDT refactoring
3263 implementations do not facilitate composition of refactorings. This section will
3264 try to explain why, and also try to identify other shortcomings of both the
3265 usability and readability of the JDT refactoring source code.
3267 \subsubsection{Absence of generics in Eclipse source code}
3268 This section is not only concerning the JDT refactoring API, but also large
3269 quantities of the \name{Eclipse} source code. The code shows a striking absence of the
3270 Java language feature of generics. It is hard to read a class' interface when
3271 methods return objects or takes parameters of raw types such as \type{List} or
3272 \type{Map}. This sometimes results in having to read a lot of source code to
3273 understand what is going on, instead of relying on the available interfaces. In
3274 addition, it results in a lot of ugly code, making the use of typecasting more
3275 of a rule than an exception.
3277 \subsubsection{Composite refactorings will not appear as atomic actions}
3278 When composing primitive refactorings from the JDT, it is not possible to make
3279 them appear as being executed as one change, but only as multiple small changes.
3281 \paragraph{Missing Flexibility from JDT Refactorings.}
3282 The JDT refactorings are not made with composition of refactorings in mind. When
3283 a JDT refactoring is executed, it assumes that all conditions for it to be
3284 applied successfully can be found by reading source files that have been
3285 persisted to disk. They can only operate on the actual source material, and not
3286 (in-memory) copies thereof. This constitutes a major disadvantage when trying to
3287 compose refactorings, since if an exception occurs in the middle of a sequence
3288 of refactorings, it can leave the project in a state where the composite
3289 refactoring was only partially executed. It makes it hard to discard the changes
3290 done without monitoring and consulting the undo manager, an approach that is not
3293 \paragraph{Broken Undo History.}
3294 When designing a composed refactoring that is to be performed as a sequence of
3295 refactorings, you would like it to appear as a single change to the workspace.
3296 This implies that you would also like to be able to undo all the changes done by
3297 the refactoring in a single step. This is not the way it appears when a sequence
3298 of JDT refactorings is executed. It leaves the undo history filled up with
3299 individual undo actions corresponding to every single JDT refactoring in the
3300 sequence. This problem is not trivial to handle in \name{Eclipse}
3301 \see{sec:hackingUndoHistory}.
3304 \chapter{Source code organization and implementation
3305 details}\label{ch:implementation}
3307 \section{Source code organization}
3308 All the parts of this master's project are under version control with
3309 \name{Git}\footnote{\url{http://git-scm.com/}}.
3311 The software written is organized as some \name{Eclipse} plugins. Writing a plugin is
3312 the natural way to utilize the API of \name{Eclipse}. This also makes it possible to
3313 provide a user interface to manually run operations on selections in program
3314 source code or whole projects/packages.
3316 When writing a plugin in \name{Eclipse}, one has access to resources such as the
3317 current workspace, the open editor and the current selection.
3319 The thesis work is contained in the following Eclipse projects:
3322 \item[no.uio.ifi.refaktor] \hfill \\ This is the main Eclipse plugin
3323 project, and contains all of the business logic for the plugin.
3325 \item[no.uio.ifi.refaktor.tests] \hfill \\
3326 This project contains the tests for the main plugin.
3328 \item[no.uio.ifi.refaktor.examples] \hfill \\
3329 Contains example code used in testing. It also contains code for managing
3330 this example code, such as creating an Eclipse project from it before a test
3333 \item[no.uio.ifi.refaktor.benchmark] \hfill \\
3334 This project contains code for running search based versions of the
3335 composite refactoring over selected Eclipse projects.
3337 \item[no.uio.ifi.refaktor.releng] \hfill \\
3338 Contains the rmap, queries and target definitions needed by Buckminster on
3339 the Jenkins continuous integration server.
3343 \subsection{The no.uio.ifi.refaktor project}
3345 \subsubsection{no.uio.ifi.refaktor.analyze}
3346 This package, and its sub-packages, contains code that is used for analyzing
3347 Java source code. The most important sub-packages are presented below.
3350 \item[no.uio.ifi.refaktor.analyze.analyzers] \hfill \\
3351 This package contains source code analyzers. These are usually responsible
3352 for analyzing text selections or running specialized analyzers for different
3353 kinds of entities. Their structures are often hierarchical. This means that
3354 you have an analyzer for text selections, that in turn is utilized by an
3355 analyzer that analyzes all the selections of a method. Then there are
3356 analyzers for analyzing all the methods of a type, all the types of a
3357 compilation unit, all the compilation units of a package, and, at last, all
3358 of the packages in a project.
3360 \item[no.uio.ifi.refaktor.analyze.checkers] \hfill \\
3361 A package containing checkers. The checkers are classes used to validate
3362 that a selection can be further analyzed and chosen as a candidate for a
3363 refactoring. Invalidating properties can be such as usage of inner classes
3364 or the need for multiple return values.
3366 \item[no.uio.ifi.refaktor.analyze.collectors] \hfill \\
3367 This package contains the property collectors. Collectors are used to gather
3368 properties from a text selection. This is mostly properties regarding
3369 referenced names and their occurrences. It is these properties that make up
3370 the basis for finding the best candidates for a refactoring.
3373 \subsubsection{no.uio.ifi.refaktor.change}
3374 This package, and its sub-packages, contains functionality for manipulate source
3378 \item[no.uio.ifi.refaktor.change.changers] \hfill \\
3379 This package contains source code changers. They are used to glue together
3380 the analysis of source code and the actual execution of the changes.
3382 \item[no.uio.ifi.refaktor.change.executors] \hfill \\
3383 The executors that are responsible for making concrete changes are found in
3384 this package. They are mostly used to create and execute one or more Eclipse
3387 \item[no.uio.ifi.refaktor.change.processors] \hfill \\
3388 Contains a refactoring processor for the \MoveMethod refactoring. The code
3389 is stolen and modified to fix a bug. The related bug is described in
3390 \myref{eclipse_bug_429416}.
3394 \subsubsection{no.uio.ifi.refaktor.handlers}
3395 This package contains handlers for the commands defined in the plugin manifest.
3397 \subsubsection{no.uio.ifi.refaktor.prefix}
3398 This package contains the \type{Prefix} type that is the data representation of
3399 the prefixes found by the \type{PrefixesCollector}. It also contains the prefix
3400 set for storing and working with prefixes.
3402 \subsubsection{no.uio.ifi.refaktor.statistics}
3403 The package contains statistics functionality. Its heart is the statistics
3404 aspect that is responsible for gathering statistics during the execution of the
3405 \ExtractAndMoveMethod refactoring.
3408 \item[no.uio.ifi.refaktor.statistics.reports] \hfill \\
3409 This package contains a simple framework for generating reports from the
3410 statistics data generated by the aspect. Currently, the only available
3411 report type is a simple text report.
3416 \subsubsection{no.uio.ifi.refaktor.textselection}
3417 This package contains the two custom text selections that are used extensively
3418 throughout the project. One of them is just a subclass of the other, to support
3419 the use of the memento pattern to optimize the memory usage during benchmarking.
3421 \subsubsection{no.uio.ifi.refaktor.debugging}
3422 The package contains a debug utility class. I addition to this, the package
3423 \code{no.uio.ifi.refaktor.utils.aspects} contains a couple of aspects used for
3426 \subsubsection{no.uio.ifi.refaktor.utils}
3427 Utility package that contains all the functionality that has to do with parsing
3428 of source code. It also has utility classes for looking up handles to methods
3429 and types et cetera.
3432 \item[no.uio.ifi.refaktor.utils.caching] \hfill \\
3433 This package contains the caching manager for compilation units, along with
3434 classes for different caching strategies.
3436 \item[no.uio.ifi.refaktor.utils.nullobjects] \hfill \\
3437 Contains classes for creating different null objects. Most of the classes
3438 are used to represent null objects of different handle types. These null
3439 objects are returned from various utility classes instead of returning a
3440 \var{null} value when other values are not available.
3445 \section{Implementing source code analysis}
3446 This section gathers implementation details for the most important parts of the
3447 source code analysis for the \ExtractAndMoveMethod refactoring.
3449 \subsection{Representing prefixes}
3450 This section shows the classes responsible for representing and working with
3453 \subsubsection{The Prefix class}
3454 This class exists mainly for holding data about a prefix, such as the expression
3455 that the prefix represents and the occurrence count of the prefix within a
3456 selection. In addition to this, it has some functionality such as calculating
3457 its sub-prefixes and intersecting it with another prefix. The definition of the
3458 intersection between two prefixes is a prefix representing the longest common
3459 expression between the two.
3461 \subsubsection{The PrefixSet class}
3462 A prefix set holds elements of type \type{Prefix}. It is implemented with the
3463 help of a \typewithref{java.util}{HashMap} and contains some typical set
3464 operations, but it does not implement the \typewithref{java.util}{Set}
3465 interface, since the prefix set does not need all of the functionality a
3466 \type{Set} requires to be implemented. In addition It needs some other
3467 functionality not found in the \type{Set} interface. So due to the relatively
3468 limited use of prefix sets, and that it almost always needs to be referenced as
3469 such, and not a \type{Set<Prefix>}, it remains as an ad hoc solution to a
3472 There are two ways adding prefixes to a \type{PrefixSet}. The first is through
3473 its \method{add} method. This works like one would expect from a set. It adds
3474 the prefix to the set if it does not already contain the prefix. The other way
3475 is to \emph{register} the prefix with the set. When registering a prefix, if the
3476 set does not contain the prefix, it is just added. If the set contains the
3477 prefix, its count gets incremented. This is how the occurrence count is handled.
3479 The prefix set also computes the set of prefixes that is not enclosing any
3480 prefixes of another set. This is kind of a set difference operation only for
3483 \subsection{Property collectors}\label{propertyCollectors}
3484 The prefixes and unfixes are found by property
3485 collectors\typeref{no.uio.ifi.refaktor.extractors.collectors.PropertyCollector}.
3486 A property collector is of the \type{ASTVisitor} type, and thus visits nodes of
3487 type \type{ASTNode} of the abstract syntax tree \see{astVisitor}.
3489 \paragraph{The PrefixesCollector.}
3490 The \typewithref{no.uio.ifi.refaktor.extractors.collectors}{PrefixesCollector}
3491 finds prefixes that makes up the basis for calculating move targets for the
3492 \refa{Extract and Move Method} refactoring. It visits expression
3493 statements\typeref{org.eclipse.jdt.core.dom.ExpressionStatement} and creates
3494 prefixes from its expressions in the case of method invocations. The prefixes
3495 found are registered with a prefix set, together with all its sub-prefixes.
3497 \paragraph{The UnfixesCollector.}\label{unfixes}
3498 The \typewithref{no.uio.ifi.refaktor.extractors.collectors}{UnfixesCollector}
3499 finds unfixes within a selection. Its semantics is described in
3500 \myref{sec:unfixes}.
3502 \subsection{Checkers}\label{checkers}
3503 The checkers are a range of classes that checks that text selections comply
3504 with certain criteria. All checkers operates under the assumption that the code
3505 they check is free from compilation errors. If a
3506 \typewithref{no.uio.ifi.refaktor.analyze.analyzers}{Checker} fails, it throws a
3507 \type{CheckerException}. The checkers are managed by the
3508 \type{LegalStatementsChecker}, which does not, in fact, implement the
3509 \type{Checker} interface. It does, however, run all the checkers registered with
3510 it, and reports that all statements are considered legal if no
3511 \type{CheckerException} is thrown. Many of the checkers either extends the
3512 \type{PropertyCollector} or utilizes one or more property collectors to verify
3513 some criteria. The checkers registered with the \type{LegalStatementsChecker}
3514 are described next. They are run in the order presented below.
3516 \subsubsection{The CallToProtectedOrPackagePrivateMethodChecker}
3517 This checker is used to check that at selection does not contain a call to a
3518 method that is protected or package-private. Such a method either has the access
3519 modifier \code{protected} or it has no access modifier.
3521 The workings of the \type{CallToProtectedOrPackagePrivateMethod\-Checker} is
3522 very simple. It looks for calls to methods that are either protected or
3523 package-private within the selection, and throws an
3524 \type{IllegalExpressionFoundException} if one is found.
3526 \subsubsection{The DoubleClassInstanceCreationChecker}
3527 The \type{DoubleClassInstanceCreationChecker} checks that there are no double
3528 class instance creations where the inner constructor call takes an argument that
3529 is built up using field references.
3531 The checker visits all nodes of type \type{ClassInstanceCreation} within a
3532 selection. For all of these nodes, if its parent also is a class instance
3533 creation, it accepts a visitor that throws a
3534 \type{IllegalExpressionFoundException} if it encounters a name that is a field
3537 \subsubsection{The InstantiationOfNonStaticInnerClassChecker}
3538 The \type{InstantiationOfNonStaticInnerClassChecker} checks that selections
3539 do not contain instantiations of non-static inner classes. The
3540 \type{MoveInstanceMethodProcessor} in \name{Eclipse} does not handle such
3541 instantiations gracefully when moving a method. This problem is also related to
3542 bug\ldots \todoin{File Eclipse bug report}
3544 \subsubsection{The EnclosingInstanceReferenceChecker}
3545 The purpose of this checker is to verify that the names in a text selection are
3546 not referencing any enclosing instances. In theory, the underlying problem could
3547 be solved in some situations, but our dependency on the
3548 \type{MoveInstanceMethodProcessor} prevents this.
3551 \typewithref{no.uio.ifi.refaktor.analyze.analyzers}{EnclosingInstanceReferenceChecker}
3552 is a modified version of the
3553 \typewithref{org.eclipse.jdt.internal.corext.refactoring.structure.MoveInstanceMethod\-Processor}{EnclosingInstanceReferenceFinder}
3554 from the \type{MoveInstanceMethodProcessor}. Wherever the
3555 \type{EnclosingInstanceReferenceFinder} would create a fatal error status, the
3556 checker will throw a \type{CheckerException}.
3558 The checker works by first finding all of the enclosing types of a selection.
3559 Thereafter, it visits all the simple names of the selection to check that they
3560 are not references to variables or methods declared in any of the enclosing
3561 types. In addition, the checker visits \var{this}-expressions to verify that no
3562 such expressions are qualified with any name.
3564 \subsubsection{The ReturnStatementsChecker}\label{returnStatementsChecker}
3565 The checker for return statements is meant to verify that a text selection is
3566 consistent regarding return statements.
3568 If the selection is free from return statements, then the checker validates. So
3569 this is the first thing the checker investigates.
3571 If the checker proceeds any further, it is because the selection contains one
3572 or more return statements. The next test is therefore to check if the last
3573 statement of the selection ends in either a return or a throw statement. The
3574 responsibility for checking that the last statement of the selection eventually
3575 ends in a return or throw statement, is put on the
3576 \type{LastStatementOfSelectionEndsInReturnOrThrowChecker}. For every node
3577 visited, if the node is a statement, it does a test to see if the statement is a
3578 return, a throw or if it is an implicit return statement. If this is the case,
3579 no further checking is done. This checking is done in the \code{preVisit2}
3580 method \see{astVisitor}. If the node is not of a type that is being handled by
3581 its type-specific visit method, the checker performs a simple test. If the node
3582 being visited is not the last statement of its parent that is also enclosed by
3583 the selection, an \type{IllegalStatementFoundException} is thrown. This ensures
3584 that all statements are taken care of, one way or the other. It also ensures
3585 that the checker is conservative in the way it checks for legality of the
3588 To examine if a statement is an implicit return statement, the checker first
3589 finds the last statement declared in its enclosing method. If this statement is
3590 the same as the one under investigation, it is considered an implicit return
3591 statement. If the statements are not the same, the checker does a search to see
3592 if the statement examined is also the last statement of the method that can be
3593 reached. This includes the last statement of a block statement, a labeled
3594 statement, a synchronized statement or a try statement, that in turn is the last
3595 statement enclosed by one of the statement types listed. This search goes
3596 through all the parents of a statement until a statement is found that is not
3597 one of the mentioned acceptable parent statements. If the search ends in a
3598 method declaration, then the statement is considered to be the last reachable
3599 statement of the method, and thus it is an implicit return statement.
3601 There are two kinds of statements that are handled explicitly: If-statements and
3602 try-statements. Block, labeled and do-statements are handled by fall-through to
3605 If-statements are handled explicitly by overriding their type-specific visit
3606 method. If the then-part does not contain any return or throw statements an
3607 \type{IllegalStatementFoundException} is thrown. If it does contain a return or
3608 throw, its else-part is checked. If the else-part is non-existent, or it does
3609 not contain any return or throw statements an exception is thrown. If no
3610 exception is thrown while visiting the if-statement, its children are visited.
3612 A try-statement is checked very similar to an if-statement. Its body must
3613 contain a return or throw. The same applies to its catch clauses and finally
3614 body. Failure to validate produces an \type{IllegalStatementFoundException}.
3616 If the checker does not complain at any point, the selection is considered valid
3617 with respect to return statements.
3619 \subsubsection{The AmbiguousReturnValueChecker}
3620 This checker verifies that there are no ambiguous return values in a selection.
3622 First, the checker needs to collect some data. Those data are the binding keys
3623 for all simple names that are assigned to within the selection, including
3624 variable declarations, but excluding fields. The checker also finds out whether
3625 a return statement is found in the selection or not. No further checks of return
3626 statements are needed, since, at this point, the selection is already checked
3627 for illegal return statements \see{returnStatementsChecker}.
3629 After the binding keys of the assignees are collected, the checker searches the
3630 part of the enclosing method that is after the selection for references whose
3631 binding keys are among the collected keys. If more than one unique referral is
3632 found, or only one referral is found, but the selection also contains a return
3633 statement, we have a situation with an ambiguous return value, and an exception
3636 %\todoin{Explain why we do not need to consider variables assigned inside
3637 %local/anonymous classes. (The referenced variables need to be final and so
3640 \subsubsection{The IllegalStatementsChecker}
3641 This checker is designed to check for illegal statements.
3643 Notice that labels in break and continue statements need some special treatment.
3644 Since a label does not have any binding information, we have to search upwards
3645 in the AST to find the \type{LabeledStatement} that corresponds to the label
3646 from the break or continue statement, and check that it is contained in the
3647 selection. If the break or continue statement does not have a label attached to
3648 it, it is checked that its innermost enclosing loop or switch statement (break
3649 statements only) also is contained in the selection.
3653 \subsection{Source code analyzers}
3654 The analyzers presented in this section are used to analyze source code. The
3655 \typewithref{no.uio.ifi.refaktor.analyze.analyzers}{ExtractAndMoveMethodAnalyzer}
3656 can be used to analyze a selection, while the
3657 \typewithref{no.uio.ifi.refaktor.analyze.analyzers}{SearchBasedExtractAndMoveMethodAnalyzer}
3658 analyzes all the text selection for a method.
3661 \type{ExtractAndMoveMethodAnalyzer}}\label{extractAndMoveMethodAnalyzer}
3662 This analyzer can perform analysis and precondition checking for an
3663 \ExtractAndMoveMethod refactoring. First it checks whether a text selection is a
3664 valid selection or not, with respect to statement boundaries and that it
3665 actually contains any selections. Then it checks the legality of both
3666 extracting the selection and also moving it to another class. This checking of
3667 is performed by a range of checkers \see{checkers}. If the selection is
3668 approved as legal, it is analyzed to find the presumably best target to move the
3669 extracted method to.
3671 For finding the best suitable target the analyzer is using a
3672 \typewithref{no.uio.ifi.refaktor.analyze.collectors}{PrefixesCollector} that
3673 collects all the possible candidate targets for the refactoring. All the
3674 non-candidates are found by an
3675 \typewithref{no.uio.ifi.refaktor.analyze.collectors}{UnfixesCollector} that
3676 collects all the targets that will give some kind of error if used. (For
3677 details about the property collectors, see \myref{propertyCollectors}.) All
3678 prefixes (and unfixes) are represented by a
3679 \typewithref{no.uio.ifi.refaktor.extractors}{Prefix}, and they are collected
3680 into sets of prefixes. The safe prefixes are found by subtracting from the set
3681 of candidate prefixes the prefixes that is enclosing any of the unfixes. A
3682 prefix is enclosing an unfix if the unfix is in the set of its sub-prefixes. As
3683 an example, \code{``a.b''} is enclosing \code{``a''}, as is \code{``a''}. The
3684 safe prefixes is unified in a \type{PrefixSet}. If a prefix has only one
3685 occurrence, and is a simple expression, it is considered unsuitable as a move
3686 target. This occurs in statements such as \code{``a.foo()''}. For such
3687 statements it bares no meaning to extract and move them. It only generates an
3688 extra method and the calling of it.
3690 The most suitable target for the refactoring is found by finding the prefix with
3691 the most occurrences. If two prefixes have the same occurrence count, but they
3692 differ in the number of segments, the one with most segments is chosen.
3695 \subsubsection{The \type{SearchBasedExtractAndMoveMethodAnalyzer}}
3696 This analyzer can be used for analyzing all the possible text selections of a
3697 method and then to choose the best result out of the analysis results that are,
3698 by the analyzer, considered to be the potential candidates for the
3699 \ExtractAndMoveMethod refactoring.
3701 Before the analyzer is able to work with the text selections of a method, it
3702 needs to generate them. To do this, it parses the method to obtain a
3703 \type{MethodDeclaration} for it \see{astEclipse}. Then there is a statement
3704 lists creator that creates statements lists of the different groups of
3705 statements in the body of the method declaration. A text selections generator
3706 generates text selections of all the statement lists for the analyzer to work
3709 \paragraph{The statement lists creator}
3710 is responsible for generating lists of statements for all the possible nesting
3711 levels of statements in the method. The statement lists creator is implemented
3712 as an AST visitor \see{astVisitor}. It generates lists of statements by visiting
3713 all the blocks in the method declaration and stores their statements in a
3714 collection of statement lists. In addition, it visits all of the other
3715 statements that can have a statement as a child, such as the different control
3716 structures and the labeled statement.
3718 The switch statement is the only kind of statement that is not straight forward
3719 to obtain the child statements from. It stores all of its children in a flat
3720 list. Its switch case statements are included in this list. This means that
3721 there are potential statement lists between all of these case statements. The
3722 list of statements from a switch statement is therefore traversed, and the
3723 statements between the case statements are grouped as separate lists.
3725 The highlighted part of \myref{lst:grandExample} shows an example of how the
3726 statement lists creator would separate a method body into lists of statements.
3728 \paragraph{The text selections generator} generates text selections for each
3729 list of statements from the statement lists creator. The generator generates a
3730 text selection for every sub-sequence of statements in a list. For a sequence of
3731 statements, the first statement and the last statement span out a text
3734 In practice, the text selections are calculated by only one traversal of the
3735 statement list. There is a set of generated text selections. For each statement,
3736 there is created a temporary set of selections, in addition to a text selection
3737 based on the offset and length of the statement. This text selection is added to
3738 the temporary set. Then the new selection is added with every selection from the
3739 set of generated text selections. These new selections are added to the
3740 temporary set. Then the temporary set of selections is added to the set of
3741 generated text selections. The result of adding two text selections is a new
3742 text selection spanned out by the two addends.
3746 \def\charwidth{5.7pt}
3747 \def\indent{4*\charwidth}
3748 \def\lineheight{\baselineskip}
3749 \def\mintedtop{\lineheight}
3751 \begin{tikzpicture}[overlay, yscale=-1]
3752 \tikzstyle{overlaybox}=[fill=lightgray,opacity=0.2]
3754 \draw[overlaybox] (2*\charwidth,\mintedtop) rectangle
3755 +(18*\charwidth,\lineheight);
3757 \draw[overlaybox] (2*\charwidth,\mintedtop+\lineheight) rectangle
3758 +(18*\charwidth,\lineheight);
3760 \draw[overlaybox] (2*\charwidth,\mintedtop+3*\lineheight) rectangle
3761 +(18*\charwidth,\lineheight);
3763 \draw[overlaybox] (\indent-3*\charwidth,\mintedtop) rectangle
3764 +(20*\charwidth,2*\lineheight);
3766 \draw[overlaybox] (3*\charwidth,\mintedtop+\lineheight) rectangle
3767 +(16*\charwidth,3*\lineheight);
3769 \draw[overlaybox] (\indent,\mintedtop) rectangle
3770 +(14*\charwidth,4*\lineheight);
3772 \begin{minted}{java}
3778 \caption{Example of how the text selections generator would generate text
3779 selections based on a lists of statements. Each highlighted rectangle
3780 represents a text selection.}
3781 \label{lst:textSelectionsExample}
3783 \todoin{fix \myref{lst:textSelectionsExample}? Text only? All
3784 sub-sequences\ldots}
3787 \paragraph{Finding the candidate} for the refactoring is done by analyzing all
3788 the generated text selections with an \type{ExtractAndMoveMethodAnalyzer}
3789 \see{extractAndMoveMethodAnalyzer}. If the analyzer generates a useful result,
3790 an \type{ExtractAndMoveMethod\-Candidate} is created from it, which is kept in a
3791 list of potential candidates. If no candidates are found, the
3792 \type{NoTargetFoundException} is thrown.
3794 Since only one of the candidates can be chosen, the analyzer must sort out which
3795 candidate to choose. The sorting is done by the static \method{sort} method of
3796 \type{Collections}. The comparison in this sorting is done by an
3797 \type{ExtractAndMoveMethodCandidateComparator}. The implementation used is the
3798 \type{FavorNoUnfixesCandidateComparator}. Its sort criteria are the same as in
3799 \myref{sec:choosingSelection}.
3802 \section{Composite refactoring implementations}
3803 This section will present how composite refactorings are implemented within the
3804 bounds of the Eclipse platform and the JDT.
3806 \subsection{A simple ad hoc model}
3807 As pointed out in \myref{ch:jdt_refactorings}, the \name{Eclipse} JDT refactoring model
3808 is not very well suited for making composite refactorings. Therefore a simple
3809 model using changer objects (of type \type{RefaktorChanger}) is used as an
3810 abstraction layer on top of the existing \name{Eclipse} refactorings, instead of
3811 extending the \typewithref{org.eclipse.ltk.core.refactoring}{Refactoring} class.
3813 The use of an additional abstraction layer is a deliberate choice. It is due to
3814 the problem of creating a composite
3815 \typewithref{org.eclipse.ltk.core.refactoring}{Change} that can handle text
3816 changes that interfere with each other. Thus, a \type{RefaktorChanger} may, or
3817 may not, take advantage of one or more existing refactorings, but it is always
3818 intended to make a change to the workspace.
3820 \paragraph{The typical \type{RefaktorChanger}.}
3821 The typical refaktor changer class has two responsibilities: Checking
3822 preconditions and executing changes. This is not too different from the
3823 responsibilities of an LTK refactoring, with the distinction that a refaktor
3824 changer also executes the change, while an LTK refactoring is only responsible
3825 for creating the object that can later be used to do that job.
3827 Checking of preconditions is typically done by an
3828 \typewithref{no.uio.ifi.refaktor.analyze.analyzers}{Analyzer}. If the
3829 preconditions validate, the upcoming changes are executed by an
3830 \typewithref{no.uio.ifi.refaktor.change.executors}{Executor}.
3832 \subsection{A simple Extract and Move Method refactoring}
3833 This section describes the implementation of a simple refactoring, that for a
3834 given text selection will analyze it and perform the \ExtractAndMoveMethod
3835 refactoring if a suitable move target is found within the selection.
3838 \paragraph{The ExtractAndMoveMethodChanger.}
3840 changer\footnote{\type{no.uio.ifi.refaktor.changers.ExtractAndMoveMethodChanger}}
3841 is a subclass of the class
3842 \typewithref{no.uio.ifi.refaktor.changers}{RefaktorChanger}. It is responsible
3843 for analyzing and finding the best target for, and also executing, an
3844 \ExtractAndMoveMethod refactoring. This particular changer is the one of my
3845 changers that is closest to being a true LTK refactoring. It can be reworked to
3846 be one if the problems with overlapping changes are resolved.
3848 The changer requires a text selection and the name of the new method, or else a
3849 method name will be generated. The selection has to be of the type
3850 \typewithref{no.uio.ifi.refaktor.utils}{CompilationUnitTextSelection}. This
3851 class is a custom extension to
3852 \typewithref{org.eclipse.jface.text}{TextSelection}, that in addition to the
3853 basic offset, length and similar methods, also carry an instance of the
3854 underlying compilation unit handle for the selection.
3856 The analysis and precondition checking for this changer is done by an
3857 \type{ExtractAndMoveMethodAnalyzer} \see{extractAndMoveMethodAnalyzer}, and the
3858 execution is done by an \type{ExtractAndMoveMethodExecutor}.
3861 \type{ExtractAndMoveMethodExecutor}.}\label{extractAndMoveMethodExecutor}
3862 If the analysis finds a possible target for the composite refactoring, it is
3864 \typewithref{no.uio.ifi.refaktor.change.executors}{ExtractAndMoveMethodExecutor}.
3865 It is composed of the two executors known as
3866 \typewithref{no.uio.ifi.refaktor.change.executors}{ExtractMethodRefactoringExecutor}
3868 \typewithref{no.uio.ifi.refaktor.change.executors}{MoveMethod\-RefactoringExecutor}.
3869 The \type{ExtractAndMoveMethodExecutor} is responsible for gluing the two
3870 together by feeding the \type{MoveMethod\-RefactoringExecutor} with the
3871 resources needed after executing the extract method refactoring.
3873 \paragraph{The \type{ExtractMethodRefactoringExecutor}.}
3874 This executor is responsible for creating and executing an instance of the
3875 \type{ExtractMethodRefactoring} class. It is also responsible for collecting
3876 some post execution resources that can be used to find the method handle for the
3877 extracted method, as well as information about its parameters, including the
3878 variable they originated from.
3880 \paragraph{The \type{MoveMethodRefactoringExecutor}.}
3881 This executor is responsible for creating and executing an instance of the
3882 \type{MoveRefactoring}. The move refactoring is a processor-based refactoring,
3883 and for the \refa{Move Method} refactoring it is the \type{MoveInstanceMethodProcessor}
3886 The handle for the method to be moved is found on the basis of the information
3887 gathered after the execution of the \refa{Extract Method} refactoring. The only
3888 information the \type{ExtractMethodRefactoring} is sharing after its execution,
3889 regarding finding the method handle, is the textual representation of the new
3890 method signature. Therefore it must be parsed, the strings for types of the
3891 parameters must be found and translated to a form that can be used to look up
3892 the method handle from its type handle. They have to be on the unresolved form.
3893 The name for the type is found from the original selection, since an extracted
3894 method must end up in the same type as the originating method.
3896 When analyzing a selection prior to performing the \refa{Extract Method} refactoring, a
3897 target is chosen. It has to be a variable binding, so it is either a field or a
3898 local variable/parameter. If the target is a field, it can be used with the
3899 \type{MoveInstanceMethodProcessor} as it is, since the extracted method still is
3900 in its scope. But if the target is local to the originating method, the target
3901 that is to be used for the processor must be among its parameters. Thus the
3902 target must be found among the extracted method's parameters. This is done by
3903 finding the parameter information object that corresponds to the parameter that
3904 was declared on basis of the original target's variable when the method was
3905 extracted. (The extracted method must take one such parameter for each local
3906 variable that is declared outside the selection that is extracted.) To match the
3907 original target with the correct parameter information object, the key for the
3908 information object is compared to the key from the original target's binding.
3909 The source code must then be parsed to find the method declaration for the
3910 extracted method. The new target must be found by searching through the
3911 parameters of the declaration and choose the one that has the same type as the
3912 old binding from the parameter information object, as well as the same name that
3913 is provided by the parameter information object.
3915 \subsection{An on-demand search-based Extract and Move Method refactoring}
3916 \label{searchBasedExtractAndMoveMethodChanger}
3918 \typewithref{no.uio.ifi.refaktor.change.changers}{SearchBasedExtractAndMoveMethodChanger}
3919 is a changer whose purpose is to automatically analyze a method, and execute the
3920 \ExtractAndMoveMethod refactoring on it if it is a suitable candidate for the
3923 First, the \type{SearchBasedExtractAndMoveMethodAnalyzer} is used to analyze the
3924 method. If the method is found to be a candidate, the result from the analysis
3925 is fed to the \type{ExtractAndMoveMethodExecutor}, whose job is to execute the
3926 refactoring \see{extractAndMoveMethodExecutor}.
3929 \subsection{Hacking the refactoring undo history}\label{sec:hackingUndoHistory}
3931 As an attempt to make multiple subsequent changes to the workspace appear as a
3932 single action (i.e. make the undo changes appear as such), I tried to alter
3933 the undo changes\typeref{org.eclipse.ltk.core.refactoring.Change} in the history
3934 of the refactorings.
3936 My first impulse was to remove the, in this case, last two undo changes from the
3937 undo manager\typeref{org.eclipse.ltk.core.refactoring.IUndoManager} for the
3938 \name{Eclipse} refactorings, and then add them to a composite
3939 change\typeref{org.eclipse.ltk.core.refactoring.CompositeChange} that could be
3940 added back to the manager. The interface of the undo manager does not offer a
3941 way to remove/pop the last added undo change, so a possible solution could be to
3942 decorate\citing{designPatterns} the undo manager, to intercept and collect the
3943 undo changes before delegating to the \method{addUndo}
3944 method\methodref{org.eclipse.ltk.core.refactoring.IUndoManager}{addUndo} of the
3945 manager. Instead of giving it the intended undo change, a null change could be
3946 given to prevent it from making any changes if run. Then one could let the
3947 collected undo changes form a composite change to be added to the manager.
3949 There is a technical challenge with this approach, and it relates to the undo
3950 manager, and the concrete implementation
3951 \typewithref{org.eclipse.ltk.internal.core.refactoring}{UndoManager2}. This
3952 implementation is designed in a way that it is not possible to just add an undo
3953 change, you have to do it in the context of an active
3954 operation\typeref{org.eclipse.core.commands.operations.TriggeredOperations}.
3955 One could imagine that it might be possible to trick the undo manager into
3956 believing that you are doing a real change, by executing a refactoring that is
3957 returning a kind of null change that is returning our composite change of undo
3958 refactorings when it is performed. But this is not the way to go.
3960 Apart from the technical problems with this solution, there is a functional
3961 problem: If it all had worked out as planned, this would leave the undo history
3962 in a dirty state, with multiple empty undo operations corresponding to each of
3963 the sequentially executed refactoring operations, followed by a composite undo
3964 change corresponding to an empty change of the workspace for rounding of our
3965 composite refactoring. The solution to this particular problem could be to
3966 intercept the registration of the intermediate changes in the undo manager, and
3967 only register the last empty change.
3969 Unfortunately, not everything works as desired with this solution. The grouping
3970 of the undo changes into the composite change does not make the undo operation
3971 appear as an atomic operation. The undo operation is still split up into
3972 separate undo actions, corresponding to the changes done by their originating
3973 refactorings. And in addition, the undo actions have to be performed separate in
3974 all the editors involved. This makes it no solution at all, but a step toward
3977 There might be a solution to this problem, but it remains to be found. The
3978 design of the refactoring undo management is partly to be blamed for this, as
3979 it is too complex to be easily manipulated.
3981 \section{Benchmarking}\label{sec:benchmarking}
3982 This part of the master's project is located in the \name{Eclipse} project
3983 \code{no.uio.ifi.refaktor.benchmark}. The purpose of it is to run the equivalent
3984 of the \type{SearchBasedExtractAndMoveMethodChanger}
3985 \see{searchBasedExtractAndMoveMethodChanger} over a larger software project,
3986 both to test its robustness but also its effect on different software metrics.
3988 \subsection{The benchmark setup}
3989 The benchmark itself is set up as a \name{JUnit} test case. This is a convenient
3990 setup, and utilizes the \name{JUnit Plugin Test Launcher}. This provides us with
3991 a fully functional \name{Eclipse} workbench. Most importantly, this gives us
3992 access to the Java Model of \name{Eclipse} \see{javaModel}.
3994 \subsubsection{The ProjectImporter}
3995 The Java project that is going to be used as the data for the benchmark, must be
3996 imported into the JUnit workspace. This is done by the
3997 \typewithref{no.uio.ifi.refaktor.benchmark}{ProjectImporter}. The importer
3998 requires the absolute path to the project description file. This file is named
3999 \code{.project} and is located at the root of the project directory.
4001 The project description is loaded to find the name of the project to be
4002 imported. The project that shall be the destination for the import is created in
4003 the workspace, on the base of the name from the description. Then an import
4004 operation is created, based on both the source and destination information. The
4005 import operation is run to perform the import.
4007 I have found no simple API call to accomplish what the importer does, which
4008 tells me that it may not be too many people performing this particular action.
4009 The solution to the problem was found on \name{Stack
4010 Overflow}\footnote{\url{https://stackoverflow.com/questions/12401297}}. It
4011 contains enough dirty details to be considered inconvenient to use, if not
4012 wrapping it in a class like my \type{ProjectImporter}. One would probably have
4013 to delve into the source code for the import wizard to find out how the import
4014 operation works, if no one had already done it.
4016 \subsection{Statistics}
4017 Statistics for the analysis and changes is captured by the
4018 \typewithref{no.uio.ifi.refaktor.aspects}{StatisticsAspect}. This an
4019 \emph{aspect} written in \name{AspectJ}.
4021 \subsubsection{AspectJ}
4022 \href{http://eclipse.org/aspectj/}{AspectJ} is an extension to the Java
4023 language, and facilitates combining aspect-oriented programming with the
4024 object-oriented programming in Java.
4026 Aspect-oriented programming is a programming paradigm that is meant to isolate
4027 so-called \emph{cross-cutting concerns} into their own modules. These
4028 cross-cutting concerns are functionalities that span over multiple classes, but
4029 may not belong naturally in any of them. It can be functionality that does not
4030 concern the business logic of an application, and thus may be a burden when
4031 entangled with parts of the source code it does not really belong. Examples
4032 include logging, debugging, optimization and security.
4034 Aspects are interacting with other modules by defining advices. The concept of
4035 an \emph{advice} is known from both aspect-oriented and functional programming.
4036 It is a function that modifies another function when the latter is run. An
4037 advice in AspectJ is somewhat similar to a method in Java. It is meant to alter
4038 the behavior of other methods, and contains a body that is executed when it is
4041 An advice can be applied at a defined \emph{pointcut}. A pointcut picks out one
4042 or more \emph{join points}. A join point is a well-defined point in the
4043 execution of a program. It can occur when calling a method defined for a
4044 particular class, when calling all methods with the same name,
4045 accessing/assigning to a particular field of a given class and so on. An advice
4046 can be declared to run both before, after returning from a pointcut, when there
4047 is thrown an exception in the pointcut or after the pointcut either returns or
4048 throws an exception. In addition to picking out join points, a pointcut can
4049 also bind variables from its context, so they can be accessed in the body of an
4050 advice. An example of a pointcut and an advice is found in
4051 \myref{lst:aspectjExample}.
4054 \begin{minted}{aspectj}
4055 pointcut methodAnalyze(
4056 SearchBasedExtractAndMoveMethodAnalyzer analyzer) :
4057 call(* SearchBasedExtractAndMoveMethodAnalyzer.analyze())
4058 && target(analyzer);
4060 after(SearchBasedExtractAndMoveMethodAnalyzer analyzer) :
4061 methodAnalyze(analyzer) {
4062 statistics.methodCount++;
4063 debugPrintMethodAnalysisProgress(analyzer.method);
4066 \caption{An example of a pointcut named \method{methodAnalyze},
4067 and an advice defined to be applied after it has occurred.}
4068 \label{lst:aspectjExample}
4071 \subsubsection{The Statistics class}
4072 The statistics aspect stores statistical information in an object of type
4073 \type{Statistics}. As of now, the aspect needs to be initialized at the point in
4074 time where it is desired that it starts its data gathering. At any point in time
4075 the statistics aspect can be queried for a snapshot of the current statistics.
4077 The \type{Statistics} class also includes functionality for generating a report
4078 of its gathered statistics. The report can be given either as a string or it can
4079 be written to a file.
4081 \subsubsection{Advices}
4082 The statistics aspect contains advices for gathering statistical data from
4083 different parts of the benchmarking process. It captures statistics from both
4084 the analysis part and the execution part of the composite \ExtractAndMoveMethod
4087 For the analysis part, there are advices to count the number of text selections
4088 analyzed and the number of methods, types, compilation units and packages
4089 analyzed. There are also advices that counts for how many of the methods there
4090 are found a selection that is a candidate for the refactoring, and for how many
4091 methods there are not.
4093 There exist advices for counting both the successful and unsuccessful executions
4094 of all the refactorings. Both for the \ExtractMethod and \MoveMethod
4095 refactorings in isolation, as well as for the combination of them.
4097 \subsection{Optimizations}
4098 When looking for possible optimizations for the benchmarking process, I used the
4099 \name{VisualVM}\footnote{\url{http://visualvm.java.net/}} \gloss{profiler} for
4100 the Java Virtual Machine to both profile the application and also to make memory
4103 \subsubsection{Caching}
4104 When \gloss{profiling} the benchmark process before making any optimizations, it
4105 early became apparent that the parsing of source code was a place to direct
4106 attention toward. This discovery was done when only \emph{analyzing} source
4107 code, before trying to do any \emph{manipulation} of it. Caching of the parsed
4108 ASTs seemed like the best way to save some time, as expected. With only a simple
4109 cache of the most recently used AST, the analysis time was speeded up by a
4110 factor of around 20. This number depends a little upon which type of system the
4113 The caching is managed by a cache manager, that now, by default, utilizes the
4114 not so well known feature of Java called a \emph{soft reference}. Soft
4115 references are best explained in the context of weak references. A \emph{weak
4116 reference} is a reference to an object instance that is only guaranteed to
4117 persist as long as there is a \emph{strong reference} or a soft reference
4118 referring the same object. If no such reference is found, its referred object is
4119 garbage collected. A strong reference is basically the same as a regular Java
4120 reference. A soft reference has the same guarantees as a week reference when it
4121 comes to its relation to strong references, but it is not necessarily garbage
4122 collected if there are no strong references to it. A soft reference \emph{may}
4123 reside in memory as long as the JVM has enough free memory in the heap. A soft
4124 reference will therefore usually perform better than a weak reference when used
4125 for simple caching and similar tasks. The way to use a soft/weak reference is to
4126 as it for its referent. The return value then has to be tested to check that it
4127 is not \var{null}. For the basic usage of soft references, see
4128 \myref{lst:softReferenceExample}. For a more thorough explanation of weak
4129 references in general, see\citing{weakRef2006}.
4132 \begin{minted}{java}
4134 Object strongRef = new Object();
4137 SoftReference<Object> softRef =
4138 new SoftReference<Object>(new Object());
4140 // Using the soft reference
4141 Object obj = softRef.get();
4146 \caption{Showing the basic usage of soft references. Weak references is used the
4147 same way. {\footnotesize (The references are part of the \code{java.lang.ref}
4149 \label{lst:softReferenceExample}
4152 The cache based on soft references has no limit for how many ASTs it caches. It
4153 is generally not advisable to keep references to ASTs for prolonged periods of
4154 time, since they are expensive structures to hold on to. For regular plugin
4155 development, \name{Eclipse} recommends not creating more than one AST at a time to
4156 limit memory consumption. Since the benchmarking has nothing to do with user
4157 experience, and throughput is everything, these advices are intentionally
4158 ignored. This means that during the benchmarking process, the target \name{Eclipse}
4159 application may very well work close to its memory limit for the heap space for
4160 long periods during the benchmark.
4162 \subsubsection{Candidates stored as mementos}
4163 When performing large scale analysis of source code for finding candidates to
4164 the \ExtractAndMoveMethod refactoring, memory is an issue. One of the inputs to
4165 the refactoring is a variable binding. This variable binding indirectly retains
4166 a whole AST. Since ASTs are large structures, this quickly leads to an
4167 \type{OutOfMemoryError} if trying to analyze a large project without optimizing
4168 how we store the candidates' data. This means that the JVM cannot allocate more
4169 memory for our benchmark, and it exits disgracefully.
4171 A possible solution could be to just allow the JVM to allocate even more memory,
4172 but this is not a dependable solution. The allocated memory could easily
4173 supersede the physical memory of a machine, which would make the benchmark go
4176 Thus, the candidates' data must be stored in another format. Therefore, we use
4177 the \gloss{mementoPattern} to store variable binding information. This is done
4178 in a way that makes it possible to retrieve a variable binding at a later point.
4179 The data that is stored to achieve this, is the key to the original variable
4180 binding. In addition to the key, we know which method and text selection the
4181 variable is referenced in, so that we can find it by parsing the source code and
4182 search for it when it is needed.
4184 \subsection{Handling failures}
4185 Failures during the benchmarking process are logged and then ignored. The
4186 failures are represented in the statistics gathered.
4189 \section{Continuous integration}
4190 The continuous integration server
4191 \name{Jenkins}\footnote{\url{http://jenkins-ci.org/}} has been set up for the
4192 project\footnote{A work mostly done by the supervisor.}. It is used as a way to
4193 run tests and perform code coverage analysis.
4195 To be able to build the \name{Eclipse} plugins and run tests for them with Jenkins, the
4196 component assembly project
4197 \name{Buckminster}\footnote{\url{http://www.eclipse.org/buckminster/}} is used,
4198 through its plugin for Jenkins. Buckminster provides for a way to specify the
4199 resources needed for building a project and where and how to find them.
4200 Buckminster also handles the setup of a target environment to run the tests in.
4201 All this is needed because the code to build depends on an \name{Eclipse}
4202 installation with various plugins.
4204 \subsection{Problems with AspectJ}
4205 The Buckminster build worked fine until introducing AspectJ into the project.
4206 When building projects using AspectJ, there are some additional steps that need
4207 to be performed. First of all, the aspects themselves must be compiled. Then the
4208 aspects need to be woven with the classes they affect. This demands a process
4209 that does multiple passes over the source code.
4211 When using AspectJ with \name{Eclipse}, the specialized compilation and the
4212 weaving can be handled by the \name{AspectJ Development
4213 Tools}\footnote{\url{https://www.eclipse.org/ajdt/}}. This works all fine, but
4214 it complicates things when trying to build a project depending on \name{Eclipse}
4215 plugins outside of \name{Eclipse}. There is supposed to be a way to specify a
4216 compiler adapter for javac, together with the file extensions for the file types
4217 it shall operate. The AspectJ compiler adapter is called
4218 \typewithref{org.aspectj.tools.ant.taskdefs}{Ajc11CompilerAdapter}, and it works
4219 with files that has the extensions \code{*.java} and \code{*.aj}. I tried to
4220 setup this in the build properties file for the project containing the aspects,
4221 but to no avail. The project containing the aspects does not seem to be built at
4222 all, and the projects that depend on it complain that they cannot find certain
4225 I then managed to write an \name{Ant}\footnote{\url{https://ant.apache.org/}}
4226 build file that utilizes the AspectJ compiler adapter, for the
4227 \code{no.uio.ifi.refaktor} plugin. The problem was then that it could no longer
4228 take advantage of the environment set up by Buckminster. The solution to this
4229 particular problem was of a ``hacky'' nature. It involves exporting the plugin
4230 dependencies for the project to an Ant build file, and copy the exported path
4231 into the existing build script. But then the Ant script needs to know where the
4232 local \name{Eclipse} installation is located. This is no problem when building
4233 on a local machine, but to utilize the setup done by Buckminster is a problem
4234 still unsolved. To get the classpath for the build setup correctly, and here
4235 comes the most ``hacky'' part of the solution, the Ant script has a target for
4236 copying the classpath elements into a directory relative to the project
4237 directory and checking it into Git. When no \code{ECLIPSE\_HOME} property is set
4238 while running Ant, the script uses the copied plugins instead of the ones
4239 provided by the \name{Eclipse} installation when building the project. This
4240 obviously creates some problems with maintaining the list of dependencies in the
4241 Ant file, as well as remembering to copy the plugins every time the list of
4242 dependencies changes.
4244 The Ant script described above is run by Jenkins before the Buckminster setup
4245 and build. When setup like this, the Buckminster build succeeds for the projects
4246 not using AspectJ, and the tests are run as normal. This is all good, but it
4247 feels a little scary, since the reason for Buckminster not working with AspectJ
4250 The problems with building with AspectJ on the Jenkins server lasted for a
4251 while, before they were solved. This is reflected in the ``Test Result Trend''
4252 and ``Code Coverage Trend'' reported by Jenkins.
4256 \chapter{Case studies}\label{ch:caseStudies}
4258 In this chapter I will present a two case studies. This is done to give an
4259 impression of how the search-based \ExtractAndMoveMethod refactoring performs
4260 when giving it a larger project to take on. I will try to answer where it lacks,
4261 in terms of completeness, as well as showing its effect on refactored source
4264 The first and primary case, is refactoring source code from the \name{Eclipse
4265 JDT UI} project. The project is chosen because it is a well-known open-source
4266 project, still in development, with a large code base that is written by many
4267 different people over several years. The code is installed in a large number of
4268 \name{Eclipse} applications worldwide, and many other projects build on the
4269 Eclipse platform. For a long time, it was even the official IDE for Android
4270 development. All this means that Eclipse must be seen as a good representative
4271 for professionally written Java source code. It is also the home for most of the
4272 JDT refactoring code.
4274 For the second case, the \ExtractAndMoveMethod refactoring is fed the
4275 \code{no.uio.ifi.refaktor} project. This is done as a variation of the
4276 ``dogfooding'' methodology.
4279 For conducting these experiments, three software tools are used. Two of the
4280 tools both use Eclipse as their platform. The first is our own tool, described
4281 in \myref{sec:benchmarking}, written to be able to run the \ExtractAndMoveMethod
4282 refactoring as a batch process. It analyzes and refactors all the methods of a
4283 project in sequence. The second is JUnit, which is used for running the
4284 project's own unit tests on the target code both before and after it is
4285 refactored. The last tool that is used is a code quality management tool, called
4286 \name{SonarQube}. It can be used to perform different tasks for assuring code
4287 quality, but we are only going to take advantage of one of its main features,
4288 namely quality profiles.
4290 A quality profile is used to define a set of coding rules that a project is
4291 supposed to comply with. Failure to following these rules will be recorded as
4292 so-called ``issues'', marked as having one of several degrees of severities,
4293 ranging from ``info'' to ``blocker'', where the latter one is the most severe.
4294 The measurements done for these case studies are therefore not presented as
4295 fine-grained software metrics results, but rather as the number of issues for
4298 In its analysis, \name{SonarQube} discriminates between functions and accessors.
4299 Accessors are methods that are recognized as setters or getters.
4301 In addition to the coding rules defined through quality profiles,
4302 \name{SonarQube} calculates the complexity of source code. The metric that is
4303 used is cyclomatic complexity, developed by Thomas J. McCabe in
4304 1976\citing{mccabeComplexity1976}. In this metric, functions have an initial
4305 complexity of 1, and whenever the control flow of a function splits, the
4306 complexity increases by
4307 one\footnote{\url{http://docs.codehaus.org/display/SONAR/Metric+definitions}}.
4308 Accessors are not counted in the complexity analysis.
4310 Specifications for the computer used during the experiments are shown in
4311 \myref{tab:experimentComputerSpecs}.
4314 \caption{Specifications for experiment computer.}
4315 \label{tab:experimentComputerSpecs}
4317 \begin{tabularx}{\textwidth}{@{}>{\bfseries}L{0.35}R{1.65}@{}}
4319 \spancols{2}{Hardware} \\
4321 Model & Lenovo ThinkPad Edge S430 \\
4322 Processor & Intel\textregistered{} Core\texttrademark{}
4323 i5-3210M\linebreak[4] (2.5 GHz/3.1 GHz (turbo),
4324 2 cores, 4 threads, 3 MB Cache) \\
4325 Memory & 8 GB DDR3 1600 MHz \\
4326 Storage & 500 GB HDD (7200 RPM) + 16 GB SSD Cache for Lenovo Hard Disk Drive
4327 Performance Booster \\
4329 \spancols{2}{Operating system} \\
4331 Distribution & Ubuntu 12.10 \\
4332 Kernel & Linux 3.5.0-49-generic (x86\_64) \\
4339 \section{The \name{SonarQube} quality profile}
4340 The quality profile that is used with \name{SonarQube} in these case studies has got
4341 the name \name{IFI Refaktor Case Study} (version 6). The rules defined in the
4342 profile are chosen because they are the available rules found in \name{SonarQube} that
4343 measures complexity and coupling. Now follows a description of the rules in the
4344 quality profile. The values that are set for these rules are listed in
4345 \myref{tab:qualityProfile1}.
4348 \item[Avoid too complex class] is a rule that measures cyclomatic complexity
4349 for every statement in the body of a class, except for setters and getter.
4350 The threshold value set is its default value of 200.
4352 \item[Classes should not be coupled to too many other classes ] is a rule that
4353 measures how many other classes a class depends upon. It does not count the
4354 dependencies of nested classes. It is meant to promote the Single
4355 Responsibility Principle. The metric for the rule resembles the CBO metric
4356 that is described in \myref{sec:CBO}, but is only considering outgoing
4357 dependencies. The max value for the rule is chosen on the basis of an
4358 empirical study by Raed Shatnawi, which concludes that the number 9 is the
4359 most useful threshold for the CBO metric\citing{shatnawiQuantitative2010}.
4360 This study is also performed on Eclipse source code, so this threshold value
4361 should be particularly well suited for the Eclipse JDT UI case in this
4364 \item[Control flow statements \ldots{} should not be nested too deeply] is
4365 a rule that is meant to counter ``Spaghetti code''. It measures the nesting
4366 level of \emph{if}, \emph{for}, \emph{while}, \emph{switch} and \emph{try}
4367 statements. The nesting levels start at 1. The max value set is its default
4370 \item[Methods should not be too complex] is a rule that measures cyclomatic
4371 complexity the same way as the ``Avoid too complex class'' rule. The max
4372 value used is 10, which ``seems like a reasonable, but not magical, upper
4373 limit``\citing{mccabeComplexity1976}.
4375 \item[Methods should not have too many lines] is a rule that simply measures
4376 the number of lines in methods. A threshold value of 20 is used for this
4377 metric. This is based on my own subjective opinions, as the default value of
4378 100 describes method bodies that do not even fit on most screens.
4380 \item[NPath Complexity] is a rule that measures the number of possible
4381 execution paths through a function. The value used is the default value of
4382 200, which seems like a recognized threshold for this metric.
4384 \item[Too many methods] is a rule that measures the number of methods in a
4385 class. The threshold value used is the default value of 10.
4391 \caption{The \name{IFI Refaktor Case Study} quality profile (version 6).}
4392 \label{tab:qualityProfile1}
4394 \begin{tabularx}{\textwidth}{@{}>{\bfseries}L{1.5}R{0.5}@{}}
4396 \textbf{Rule} & \textbf{Max value} \\
4398 Avoid too complex class & 200 \\
4399 Classes should not be coupled to too many other classes (Single
4400 Responsibility Principle) & 9 \\
4401 Control flow statements \ldots{} should not be nested too deeply &
4403 Methods should not be too complex & 10 \\
4404 Methods should not have too many lines & 20 \\
4405 NPath Complexity & 200 \\
4406 Too many methods & 10 \\
4413 A precondition for the source code that is going to be the target for a series
4414 of \ExtractAndMoveMethod refactorings, is that it is organized as an Eclipse
4415 project. It is also assumed that the code is free from compilation errors.
4417 \section{The experiment}
4418 For a given project, the first job that is done, is to refactor its source code.
4419 The refactoring batch job produces three things: The refactored project,
4420 statistics gathered during the execution of the series of refactorings, and an
4421 error log describing any errors happening during this execution. See
4422 \myref{sec:benchmarking} for more information about how the refactorings are
4425 After the refactoring process is done, the before- and after-code is analyzed
4426 with \name{SonarQube}. The analysis results are then stored in a database and
4427 displayed through a \name{SonarQube} server with a web interface.
4429 The before- and after-code is also tested with their own unit tests. This is
4430 done to discover any changes in the semantic behavior of the refactored code,
4431 within the limits of these tests.
4433 \section{Case 1: The Eclipse JDT UI project}
4434 This case is the ultimate test for our \ExtractAndMoveMethod refactoring. The
4435 target source code is massive. With its over 300,000 lines of code\footnote{For
4436 all uses of ``lines of code'' we follow the definition from \name{SonarQube}.
4437 LOC = the number of physical lines containing a character which is neither
4438 whitespace or part of a comment.} and more than 25,000 methods, it is a
4439 formidable task to perform automated changes on it. There should be plenty of
4440 situations where things can go wrong, and, as we shall see later, they do.
4442 I will start by presenting some statistics from the refactoring execution,
4443 before I pick apart the \name{SonarQube} analysis and conclude by commenting on
4444 the results from the unit tests. The configuration for the experiment is
4445 specified in \myref{tab:configurationCase1}.
4448 \caption{Configuration for Case 1.}
4449 \label{tab:configurationCase1}
4451 \begin{tabularx}{\textwidth}{@{}>{\bfseries}L{0.67}L{1.33}@{}}
4453 \spancols{2}{Benchmark data} \\
4455 Launch configuration & CaseStudy.launch \\
4456 Project & no.uio.ifi.refaktor.benchmark \\
4457 Repository & gitolite@git.uio.no:ifi-stolz-refaktor \\
4458 Commit & 43c16c04520746edd75f8dc2a1935781d3d9de6c \\
4460 \spancols{2}{Input data} \\
4462 Project & org.eclipse.jdt.ui \\
4463 Repository & git://git.eclipse.org/gitroot/jdt/eclipse.jdt.ui.git \\
4464 Commit & f218388fea6d4ec1da7ce22432726c244888bb6b \\
4465 Branch & R3\_8\_maintenance \\
4466 Tests suites & org.eclipse.jdt.ui.tests.AutomatedSuite,
4467 org.eclipse.jdt.ui.tests.refactoring.all.\-AllAllRefactoringTests \\
4472 \subsection{Statistics}
4473 The statistics gathered during the refactoring execution is presented in
4474 \myref{tab:case1Statistics}.
4477 \caption{Statistics after batch refactoring the Eclipse JDT UI project with
4478 the \ExtractAndMoveMethod refactoring.}
4479 \label{tab:case1Statistics}
4481 \begin{tabularx}{\textwidth}{@{}>{\bfseries}L{1.5}R{0.5}@{}}
4483 \spancols{2}{Time used} \\
4485 Total time & 98m38s \\
4486 Analysis time & 14m41s (15\%) \\
4487 Change time & 74m20s (75\%) \\
4488 Miscellaneous tasks & 9m37s (10\%) \\
4490 \spancols{2}{Numbers of each type of entity analyzed} \\
4493 Compilation units & 2,097 \\
4496 Text selections & 591,500 \\
4498 \spancols{2}{Numbers for \ExtractAndMoveMethod refactoring candidates} \\
4500 Methods chosen as candidates & 2,552 \\
4501 Methods NOT chosen as candidates & 25,115 \\
4502 Candidate selections (multiple per method) & 36,843 \\
4504 \spancols{2}{\ExtractAndMoveMethod refactorings executed} \\
4506 Fully executed & 2,469 \\
4507 Not fully executed & 83 \\
4508 Total attempts & 2,552 \\
4510 \spancols{2}{Primitive refactorings executed} \\
4511 \spancols{2}{\small \ExtractMethod refactorings} \\
4513 Performed & 2,483 \\
4514 Not performed & 69 \\
4515 Total attempts & 2,552 \\
4517 \spancols{2}{\small \MoveMethod refactorings} \\
4520 Not performed & 14 \\
4521 Total attempts & 2,483 \\
4527 \subsubsection{Execution time}\label{sec:case1ExecutionTime}
4528 I consider the total execution time of approximately 1.5 hours, on a mid-level
4529 laptop computer, as being acceptable. It clearly makes the batch process
4530 unsuitable for doing any on-demand analysis or changes, but it is good enough
4531 for running periodic jobs, like over-night analysis. In comparison, the
4532 SonarQube analysis for the same project consumes about the same amount of time.
4534 As the statistics show, 75\% of the total time goes into making the actual code
4535 changes. The time consumers are here the primitive \ExtractMethod and
4536 \MoveMethod refactorings. Included in the change time is the parsing and
4537 precondition checking done by the refactorings, as well as textual changes done
4538 to files on disk. All this parsing and disk access is time-consuming, and
4539 constitutes a large part of the change time.
4541 The pure analysis time, which is the time used on finding suitable refactoring
4542 candidates, only makes up for 15\% of the total time consumed. This includes
4543 analyzing almost 600,000 text selections, while the number of attempted
4544 executions of the \ExtractAndMoveMethod refactoring is only about 2,500. So the
4545 number of executed primitive refactorings is approximately 5,000. Assuming the
4546 time used on miscellaneous tasks are used mostly for parsing source code for the
4547 analysis, we can say that the time used for analyzing code is at most 25\% of
4548 the total time. This means that for every primitive refactoring executed, we
4549 can analyze about 360 text selections. So, with an average of about 21 text
4550 selections per method, it is reasonable to say that we can analyze over 15
4551 methods in the time it takes to perform a primitive refactoring.
4553 \subsubsection{Refactoring candidates}
4554 Out of the 27,667 methods that were analyzed, 2,552 methods contained selections
4555 that were considered candidates for the \ExtractAndMoveMethod refactoring. This
4556 is roughly 9\% off the methods in the project. These 9\% of the methods had on
4557 average 14.4 text selections that were considered possible refactoring
4560 \subsubsection{Executed refactorings}
4561 2,469 out of 2,552 attempts on executing the \ExtractAndMoveMethod refactoring
4562 were successful, giving a success rate of 96.7\%. The failure rate of 3.3\%
4563 stems from situations where the analysis finds a candidate selection, but the
4564 change execution fails. This failure could be an exception that was thrown, and
4565 the refactoring aborts. It could also be the precondition checking for one of
4566 the primitive refactorings that gives us an error status, meaning that if the
4567 refactoring proceeds, the code will contain compilation errors afterwards,
4568 forcing the composite refactoring to abort.
4570 Out of the 2,552 \ExtractMethod refactorings that were attempted executed, 69 of
4571 them failed. This gives a failure rate of 2.7\% for the primitive refactoring.
4572 In comparison, the \MoveMethod refactoring had a failure rate of 0.6 \% of the
4573 2,483 attempts on the refactoring.
4575 The failure rates for the refactorings are not that bad, if we also take into
4576 account that the pre-refactoring analysis is incomplete
4577 \see{par:incompleteness}.
4579 \subsection{\name{SonarQube} analysis}
4580 Results from the \name{SonarQube} analysis are shown in
4581 \myref{tab:case1ResultsProfile1}.
4584 \caption{Results for analyzing the Eclipse JDT UI project, before and after
4585 the refactoring, with \name{SonarQube} and the \name{IFI Refaktor Case Study}
4586 quality profile. (Bold numbers are better.)}
4587 \label{tab:case1ResultsProfile1}
4589 \begin{tabularx}{\textwidth}{@{}>{\bfseries}L{1.5}R{0.25}R{0.25}@{}}
4591 \textnormal{Number of issues for each rule} & Before & After \\
4593 Avoid too complex class & 81 & \textbf{79} \\
4594 Classes should not be coupled to too many other classes (Single
4595 Responsibility Principle) & \textbf{1,098} & 1,199 \\
4596 Control flow statements \ldots{} should not be nested too deeply & 1,375 &
4598 Methods should not be too complex & 1,518 & \textbf{1,452} \\
4599 Methods should not have too many lines & 3,396 & \textbf{3,291} \\
4600 NPath Complexity & 348 & \textbf{329} \\
4601 Too many methods & \textbf{454} & 520 \\
4603 Total number of issues & 8,270 & \textbf{8,155} \\
4606 \spancols{3}{Complexity} \\
4608 Per function & 3.6 & \textbf{3.3} \\
4609 Per class & \textbf{29.5} & 30.4 \\
4610 Per file & \textbf{44.0} & 45.3 \\
4612 Total complexity & \textbf{84,765} & 87,257 \\
4615 \spancols{3}{Numbers of each type of entity analyzed} \\
4617 Files & 1,926 & 1,926 \\
4618 Classes & 2,875 & 2,875 \\
4619 Functions & 23,744 & 26,332 \\
4620 Accessors & 1,296 & 1,019 \\
4621 Statements & 162,768 & 165,145 \\
4622 Lines of code & 320,941 & 329,112 \\
4624 Technical debt (in days) & \textbf{1,003.4} & 1,032.7 \\
4629 \subsubsection{Diversity in the number of entities analyzed}
4630 The analysis performed by \name{SonarQube} is reporting fewer methods than found
4631 by the pre-refactoring analysis. \name{SonarQube} discriminates between
4632 functions (methods) and accessors, so the 1,296 accessors play a part in this
4633 calculation. \name{SonarQube} also has the same definition as our plugin when
4634 it comes to how a class is defined. Therefore it seems like \name{SonarQube}
4635 misses 277 classes that our plugin handles. This can explain why the {SonarQube}
4636 report differs from our numbers by approximately 2,500 methods.
4638 \subsubsection{Complexity}
4639 On all complexity rules that works on the method level, the number of issues
4640 decreases with between 3.1\% and 6.5\% from before to after the refactoring. The
4641 average complexity of a method decreases from 3.6 to 3.3, which is an
4642 improvement of about 8.3\%. So, on the method level, the refactoring must be
4643 said to have a slightly positive impact. This is due to the extraction of a lot
4644 of methods, making the average method size smaller.
4646 The improvement in complexity on the method level is somewhat traded for
4647 complexity on the class level. The complexity per class metric is worsened by
4648 3\% from before to after. The issues for the ``Too many methods'' rule also
4649 increases by 14.5\%. These numbers indicate that the refactoring makes quite a
4650 lot of the classes a little more complex overall. This is the expected outcome,
4651 since the \ExtractAndMoveMethod refactoring introduces almost 2,500 new methods
4654 The only number that can save the refactoring's impact on complexity on the
4655 class level, is the ``Avoid too complex class'' rule. It improves with 2.5\%,
4656 thus indicating that the complexity is moderately better distributed between the
4657 classes after the refactoring than before.
4659 \subsubsection{Coupling}
4660 One of the hopes when starting this project, was to be able to make a
4661 refactoring that could lower the coupling between classes. Better complexity at
4662 the method level is a not very unexpected byproduct of dividing methods into
4663 smaller parts. Lowering the coupling on the other hand, is a far greater task.
4664 This is also reflected in the results for the only coupling rule defined in the
4665 \name{SonarQube} quality profile, namely the ``Classes should not be coupled to
4667 other classes (Single Responsibility Principle)'' rule.
4669 The number of issues for the coupling rule is 1,098 before the refactoring, and
4670 1,199 afterwards. This is an increase in issues of 9.2\%. These numbers can be
4671 interpreted two ways. The first possibility is that our assumptions are wrong,
4672 and that increasing indirection does not decrease coupling between classes. The
4673 other possibility is that our analysis and choices of candidate text selections
4674 are not good enough. I vote for the second possibility. (Voting against the
4675 public opinion may also be a little bold.)
4677 \subsubsection{An example of what makes the number of coupling issues
4678 grow}\label{sec:case1IssuesExample}
4679 \Myref{lst:sonarJDTExampleBefore} shows a portion of the class
4680 \typewithref{org.eclipse.jdt.ui.actions}{ShowActionGroup} from the JDT UI
4681 project before it is refactored with the search-based \ExtractAndMoveMethod
4682 refactoring. Before the refactoring, the \type{ShowActionGroup} class has 12
4683 outgoing dependencies (reported by \name{SonarQube}).
4685 \begin{listing}[htb]
4686 \begin{minted}[linenos,samepage]{java}
4687 public class ShowActionGroup extends ActionGroup {
4689 private void initialize(IWorkbenchSite site,
4690 boolean isJavaEditor) {
4692 ISelectionProvider provider= fSite.getSelectionProvider();
4693 ISelection selection= provider.getSelection();
4694 fShowInPackagesViewAction.update(selection);
4695 if (!isJavaEditor) {
4696 provider.addSelectionChangedListener(
4697 fShowInPackagesViewAction);
4702 \caption{Portion of the \type{ShowActionGroup} class before refactoring.}
4703 \label{lst:sonarJDTExampleBefore}
4706 During the benchmark process, the search-based \ExtractAndMoveMethod refactoring
4707 extracts the lines 6 to 12 of the code in \myref{lst:sonarJDTExampleBefore}, and
4708 moves the new method to the move target, which is the field
4709 \var{fShowInPackagesViewAction} with type
4710 \typewithref{org.eclipse.jdt.ui.actions}{ShowInPackageViewAction}. The result is
4711 shown in \myref{lst:sonarJDTExampleAfter}.
4713 \begin{listing}[htb]
4714 \begin{minted}[linenos,samepage]{java}
4715 public class ShowActionGroup extends ActionGroup {
4717 private void initialize(IWorkbenchSite site,
4718 boolean isJavaEditor) {
4720 fShowInPackagesViewAction.generated_8019497110545412081(
4721 this, isJavaEditor);
4726 \begin{minted}[linenos,samepage]{java}
4727 public class ShowInPackageViewAction
4728 extends SelectionDispatchAction {
4730 public void generated_8019497110545412081(
4731 ShowActionGroup showactiongroup, boolean isJavaEditor) {
4732 ISelectionProvider provider=
4733 showactiongroup.fSite.getSelectionProvider();
4734 ISelection selection= provider.getSelection();
4736 if (!isJavaEditor) {
4737 provider.addSelectionChangedListener(this);
4742 \caption{Portions of the classes \type{ShowActionGroup} and
4743 \type{ShowInPackageViewAction} after refactoring.}
4744 \label{lst:sonarJDTExampleAfter}
4747 After the refactoring, the \type{ShowActionGroup} has only 11 outgoing
4748 dependencies. It no longer depends on the \type{ISelection} type. So our
4749 refactoring managed to get rid of one dependency, which is exactly what we
4750 wanted. The only problem is, that now the \type{ShowInPackageViewAction} class
4751 has got two new dependencies, in the \type{ISelectionProvider} and the
4752 \type{ISelection} types. The bottom line is that we eliminated one dependency,
4753 but introduced two more, ending up with a program that has more dependencies now
4754 than when we started.
4756 What can happen in many situations where the \ExtractAndMoveMethod refactoring
4757 is performed, is that the \MoveMethod refactoring ``drags'' with it references
4758 to classes that are unknown to the method destination. If the refactoring
4759 happens to be so lucky that it removes a dependency from one class, it might as
4760 well introduce a couple of new dependencies to another class, as shown in the
4761 previous example. In those situations where a destination class does not know
4762 about the originating class of a moved method, the \MoveMethod refactoring most
4763 certainly will introduce a dependency. This is because there is a
4764 bug\footnote{\href{https://bugs.eclipse.org/bugs/show\_bug.cgi?id=228635}{Eclipse
4765 Bug 228635 - [move method] unnecessary reference to source}} in the refactoring,
4766 making it pass an instance of the originating class as a reference to the moved
4767 method, regardless of whether the reference is used in the method body or not.
4769 There is also the possibility that the heuristics used to find candidate text
4770 selections are not good enough. There is work to be done with fine-tuning the
4771 heuristics and to complete the analysis part of this project.
4773 \subsubsection{Totals}
4774 On the bright side, the total number of issues is lower after the refactoring
4775 than it was before. Before the refactoring, the total number of issues was
4776 8,270, and after it is 8,155. This is an improvement of 1.4\%.
4778 The down side is that \name{SonarQube} shows that the total cyclomatic
4779 complexity has increased by 2.9\%, and that the (more questionable) ``technical
4780 debt'' has increased from 1,003.4 to 1,032.7 days, also a deterioration of
4781 2.9\%. Although these numbers are similar, no correlation has been found
4784 \subsection{Unit tests}
4785 The tests that have been run for the \name{Eclipse JDT UI} project, are the
4786 test suites specified as the main test suites on the JDT UI wiki page on how to
4788 project\footnote{\url{https://wiki.eclipse.org/JDT\_UI/How\_to\_Contribute\#Unit\_Testing}}.
4789 The results from these tests are shown in \myref{tab:case1UnitTests}.
4792 \caption{Results from the unit tests run for the Eclipse JDT UI project,
4793 before and after the refactoring.}
4794 \label{tab:case1UnitTests}
4796 \begin{tabularx}{\textwidth}{@{}>{\bfseries}L{1}R{0.5}R{0.5}@{}}
4798 \textnormal{AutomatedSuite} & Before & After \\
4800 Runs & 2007/2007 & 2007/2007 \\
4804 \spancols{2}{AllAllRefactoringTests} \\
4806 Runs & 3815/3816 & 3815/3816 \\
4807 Errors & 2 & 2257 \\
4813 \subsubsection{Before the refactoring}
4814 Running the tests for the before-code of Eclipse JDT UI yielded 4 errors and 3
4815 failures for the \type{AutomatedSuite} test suite (2,007 test cases), and 2
4816 errors and 3 failures for the \type{AllAllRefactoringTests} test suite (3,816
4819 \subsubsection{After the refactoring}
4820 For the after-code of the Eclipse JDT UI project, Eclipse reports that the
4821 project contains 322 compilation errors, and a lot of other errors that
4822 follow from these. All of the errors are caused by the \ExtractAndMoveMethod
4823 refactoring. Had these errors originated from only one bug, it would not have
4824 been much of a problem, but this is not the case. By only looking at some random
4825 compilation problems in the refactored code, I came up with at least four
4826 different bugs \todo{write bug reports?} that caused those problems. I then
4827 stopped looking for more, since some of the bugs would take more time to fix
4828 than I could justify using on them at this point.
4830 One thing that can be said in my defense, is that all the compilation errors
4831 could have been avoided if the types of situations that cause them were properly
4832 handled by the primitive refactorings, which again are supplied by the Eclipse
4833 JDT UI project. All four bugs that I mentioned before are weaknesses of the
4834 \MoveMethod refactoring. If the primitive refactorings had detected the
4835 up-coming errors in their precondition checking phase, the refactorings would
4836 have been aborted, since this is how the \ExtractAndMoveMethod refactoring
4837 handles such situations. This shows that it is not safe to completely rely upon
4838 the primitive refactorings to save us if our own pre-refactoring analysis fails
4839 to detect that a compilation error will be introduced. A problem is that the
4840 source code analysis done by both the JDT refactorings and our own tool is
4843 Of course, taking into account all possible situations that could lead to
4844 compilation errors is an immense task. A complete analysis of these situations
4845 is too big of a problem for this master's project to solve. Looking at it now,
4846 this comes as no surprise, since the task is obviously also too big for the
4847 creators of the primitive \MoveMethod refactoring.
4849 Considering all these problems, it is difficult to know how to interpret the
4850 unit test results from after refactoring the Eclipse JDT UI. The
4851 \type{AutomatedSuite} reported 565 errors and 5 failures, which means that 1437,
4852 or 71.6\%, of the tests still passed. Three of the failures were the same as
4853 reported before the refactoring took place, so two of them are new. For these
4854 two cases it is not immediately apparent what makes them behave differently. The
4855 program is so complex that to analyze it to find this out, we might need more
4856 powerful methods than just manually analyzing its source code. This is somewhat
4857 characteristic for imperative programming: The programs are often hard to
4858 analyze and understand.
4860 For the \type{AllAllRefactoringTests} test suite, the three failures are gone,
4861 but the two errors have grown to 2,257 errors. I will not try to analyze those
4864 What I can say at this point, is that it is likely that the
4865 \ExtractAndMoveMethod refactoring has introduced some unintentional behavioral
4866 changes. Let us say that the refactoring introduces at least two
4867 behavior-altering changes for every 2,500 executions. More than that is
4868 difficult to say about the behavior-preserving properties of the
4869 \ExtractAndMoveMethod refactoring, at this point. What is clear, is that it
4870 would benefit from a strategy for making it perform refactoring in a safer
4873 \subsection{Conclusions}
4874 After automatically analyzing and executing the \ExtractAndMoveMethod
4875 refactoring for all the methods in the Eclipse JDT UI project, the results do
4876 not look that promising. For this case, the refactoring seems almost unusable as
4877 it is now. The error rate and measurements tell us this.
4879 The refactoring makes the code a little less complex at the method level. But
4880 this is merely a side effect of extracting methods. When it comes to the overall
4881 complexity, it is increased, although it is slightly better spread among the
4884 The pre-refactoring analysis of the \ExtractAndMoveMethod refactoring, is
4885 currently not complete enough to make the refactoring useful. It introduces too
4886 many errors in the code, and the code may change its behavior. It also remains
4887 to prove that large-scale refactoring with it can decrease the overall coupling
4888 between classes, although there are individual examples
4889 \see{sec:case1IssuesExample}.
4891 On the bright side, the performance of the refactoring process is not that bad.
4892 It shows that it is possible to make a tool the way we do, if we can make the
4893 tool do anything useful. As long as the analysis phase is not going to involve
4894 anything that uses too much disk access, a lot of analysis can be done in a
4895 reasonable amount of time.
4897 The time used on performing the actual changes excludes a trial and error
4898 approach with the tools used in this master's project. In a trial and error
4899 approach, you could for instance be using the primitive refactorings used in
4900 this project to refactor code, and only then make decisions based on the effect,
4901 possibly shown by traditional software metrics. The problem with the approach
4902 taken in this project, compared to a trial and error approach, is that using
4903 heuristics beforehand is much more complicated. But on the other hand, a trial
4904 and error approach would still need to face the challenges of producing code
4905 that does compile without errors. If using refactorings that could produce
4906 in-memory changes, a trial and error approach could be made more efficient.
4908 \section{Case 2: The \type{no.uio.ifi.refaktor} project}
4909 In this case we will see a form of the ``dogfooding'' methodology used, when
4910 refactoring our own \type{no.uio.ifi.refaktor} project with the
4911 \ExtractAndMoveMethod refactoring.
4913 In this case I will try to point out some differences from the first case, and
4914 how they impact the execution of the benchmark. The refaktor project is 39 times
4915 smaller than the Eclipse JDT UI project, measured in lines of code. This will
4916 make things a bit more transparent. It will therefore be interesting to see if
4917 this case can shed light on any aspect of our project that were lost in the
4920 The configuration for the experiment is specified in
4921 \myref{tab:configurationCase2}.
4924 \caption{Configuration for Case 2.}
4925 \label{tab:configurationCase2}
4927 \begin{tabularx}{\textwidth}{@{}>{\bfseries}L{0.67}L{1.33}@{}}
4929 \spancols{2}{Benchmark data} \\
4931 Launch configuration & CaseStudyDogfooding.launch \\
4932 Project & no.uio.ifi.refaktor.benchmark \\
4933 Repository & gitolite@git.uio.no:ifi-stolz-refaktor \\
4934 Commit & 43c16c04520746edd75f8dc2a1935781d3d9de6c \\
4936 \spancols{2}{Input data} \\
4938 Project & no.uio.ifi.refaktor \\
4939 Repository & gitolite@git.uio.no:ifi-stolz-refaktor \\
4940 Commit & 43c16c04520746edd75f8dc2a1935781d3d9de6c \\
4942 Test configuration & no.uio.ifi.refaktor.tests/ExtractTest.launch \\
4947 \subsection{Statistics}
4948 The statistics gathered during the refactoring execution is presented in
4949 \myref{tab:case2Statistics}.
4952 \caption{Statistics after batch refactoring the \type{no.uio.ifi.refaktor}
4953 project with the \ExtractAndMoveMethod refactoring.}
4954 \label{tab:case2Statistics}
4956 \begin{tabularx}{\textwidth}{@{}>{\bfseries}L{1.5}R{0.5}@{}}
4958 \spancols{2}{Time used} \\
4960 Total time & 1m15s \\
4961 Analysis time & 0m18s (24\%) \\
4962 Change time & 0m47s (63\%) \\
4963 Miscellaneous tasks & 0m10s (14\%) \\
4965 \spancols{2}{Numbers of each type of entity analyzed} \\
4968 Compilation units & 154 \\
4971 Text selections & 8,609 \\
4973 \spancols{2}{Numbers for \ExtractAndMoveMethod refactoring candidates} \\
4975 Methods chosen as candidates & 58 \\
4976 Methods NOT chosen as candidates & 1,012 \\
4977 Candidate selections (multiple per method) & 227 \\
4979 \spancols{2}{\ExtractAndMoveMethod refactorings executed} \\
4981 Fully executed & 53 \\
4982 Not fully executed & 5 \\
4983 Total attempts & 58 \\
4985 \spancols{2}{Primitive refactorings executed} \\
4986 \spancols{2}{\small \ExtractMethod refactorings} \\
4989 Not performed & 2 \\
4990 Total attempts & 58 \\
4992 \spancols{2}{\small \MoveMethod refactorings} \\
4995 Not performed & 3 \\
4996 Total attempts & 56 \\
5002 \subsubsection{Differences}
5003 There are some differences between the two projects that make them a little
5004 difficult to compare by performance.
5006 \paragraph{Different complexity.}
5007 Although the JDT UI project is 39 times greater than the refaktor project in
5008 terms of lines of code, it is only about 26 times its size measured in number of
5009 methods. This means that the average method size is smaller in the refaktor
5010 project than in the JDT project. This is also reflected in the \name{SonarQube}
5011 report, where the complexity per method for the JDT project is
5012 3.6, while the refaktor project has a complexity per method of 2.1.
5014 \paragraph{Number of selections per method.}
5015 The analysis for the JDT project processed 21 text selections per method in
5016 average. This number for the refaktor project is only 8 selections per method
5017 analyzed. This is a direct consequence of smaller methods.
5019 \paragraph{Different candidates to methods ratio.}
5020 The differences in how the projects are factored are also reflected in the
5021 ratios for how many methods that are chosen as candidates compared to the total
5022 number of methods analyzed. For the JDT project, 9\% of the methods were
5023 considered to be candidates, while for the refaktor project, only 5\% of the
5024 methods were chosen.
5026 \paragraph{The average number of possible candidate selection.}
5027 For the methods that are chosen as candidates, the average number of possible
5028 candidate selections for these methods differ quite much. For the JDT project,
5029 the number of possible candidate selections for these methods was 14.44
5030 selections per method, while the candidate methods in the refaktor project had
5031 only 3.91 candidate selections to choose from, in average.
5033 \subsubsection{Execution time}
5034 The differences in complexity, and the different candidate methods to total
5035 number of methods ratios, is shown in the distributions of the execution times.
5036 For the JDT project, 75\% of the total time was used on the actual changes,
5037 while for the refaktor project, this number was only 63\%.
5039 For the JDT project, the benchmark used on average 0.21 seconds per method in
5040 the project, while for the refaktor project it used only 0.07 seconds per
5041 method. So the process used 3 times as much time per method for the JDT project
5042 than for the refaktor project.
5044 While the JDT project is 39 times larger than the refaktor project measured in
5045 lines of code, the benchmark used about 79 times as long time on it than for the
5046 refaktor project. Relatively, this is about twice as long.
5048 Since the details of these execution times are not that relevant to this
5049 master's project, only their magnitude, I will leave them here.
5051 \subsubsection{Executed refactorings}
5052 For the composite \ExtractAndMoveMethod refactoring performed in case 2, 53
5053 successful attempts out of 58 gives a success rate of 91.4\%. This is 5.3
5054 percentage points worse than for the first case.
5056 \subsection{\name{SonarQube} analysis}
5057 Results from the \name{SonarQube} analysis are shown in
5058 \myref{tab:case2ResultsProfile1}.
5060 Not much is to be said about these results. The trends in complexity and
5061 coupling are the same. We end up a little worse after the refactoring process
5065 \caption{Results for analyzing the \var{no.uio.ifi.refaktor} project, before
5066 and after the refactoring, with \name{SonarQube} and the \name{IFI Refaktor
5067 Case Study} quality profile. (Bold numbers are better.)}
5068 \label{tab:case2ResultsProfile1}
5070 \begin{tabularx}{\textwidth}{@{}>{\bfseries}L{1.5}R{0.25}R{0.25}@{}}
5072 \textnormal{Number of issues for each rule} & Before & After \\
5074 Avoid too complex class & 1 & 1 \\
5075 Classes should not be coupled to too many other classes (Single
5076 Responsibility Principle) & \textbf{29} & 34 \\
5077 Control flow statements \ldots{} should not be nested too deeply & 24 &
5079 Methods should not be too complex & 17 & \textbf{15} \\
5080 Methods should not have too many lines & 41 & \textbf{40} \\
5081 NPath Complexity & 3 & 3 \\
5082 Too many methods & \textbf{13} & 15 \\
5084 Total number of issues & \textbf{128} & 129 \\
5087 \spancols{3}{Complexity} \\
5089 Per function & 2.1 & 2.1 \\
5090 Per class & \textbf{12.5} & 12.9 \\
5091 Per file & \textbf{13.8} & 14.2 \\
5093 Total complexity & \textbf{2,089} & 2,148 \\
5096 \spancols{3}{Numbers of each type of entity analyzed} \\
5098 Files & 151 & 151 \\
5099 Classes & 167 & 167 \\
5100 Functions & 987 & 1,045 \\
5101 Accessors & 35 & 30 \\
5102 Statements & 3,355 & 3,416 \\
5103 Lines of code & 8,238 & 8,460 \\
5105 Technical debt (in days) & \textbf{19.0} & 20.7 \\
5110 \subsection{Unit tests}
5111 The tests used for this case are the same that has been developed throughout
5112 this master's project.
5114 The code that was refactored for this case suffered from some of the problems
5115 discovered in the first case. This means that the after-code for this case also
5116 contained compilation errors, but they were not as many. The code contained only
5117 6 errors that made the code not compile.
5119 All of the six errors originated from the same bug. The bug arises in a
5120 situation where a class instance creation is moved between packages, and the
5121 class for the instance is package-private. The \MoveMethod refactoring does not
5122 detect that there will be a visibility problem, and neither does it promote the
5123 package-private class to be public.
5125 Since the errors in the refactored refaktor code were easy to fix manually, I
5126 corrected them and ran the unit tests as planned. The unit test results are
5127 shown in \myref{tab:case2UnitTests}. Before the refactoring, all tests passed.
5128 All tests also passed after the refactoring, with the six error corrections.
5129 Since the corrections done are not of a kind that could make the behavior of the
5130 program change, it is likely that the refactorings done to the
5131 \type{no.uio.ifi.refaktor} project did not change its behavior. This is also
5132 supported by the informal experiment presented next.
5135 \caption{Results from the unit tests run for the \type{no.uio.ifi.refaktor}
5136 project, before and after the refactoring (with 6 corrections done to the
5138 \label{tab:case2UnitTests}
5140 \begin{tabularx}{\textwidth}{@{}>{\bfseries}L{1}R{0.5}R{0.5}@{}}
5144 Runs & 148/148 & 148/148 \\
5151 \subsection{An additional experiment}
5152 To complete the task of ``eating my own dog food'', I conducted an experiment
5153 where I used the refactored version of the \type{no.uio.ifi.refaktor} project,
5154 with the corrections, to again refaktor ``itself''.
5156 The experiment produced code containing the same six errors as after the
5157 previous experiment. I also compared the after-code from the two experiments
5158 with a diff-tool. The only differences found were different method names. This
5159 is expected, since the method names are randomly generated by the
5160 \ExtractAndMoveMethod refactoring.
5162 The outcome of this simple experiment makes me more confident that the
5163 \ExtractAndMoveMethod refactoring made only behavior-preserving changes to the
5164 \type{no.uio.ifi.refaktor} project, apart from the compilation errors.
5166 \subsection{Conclusions}
5167 The differences in complexity between the Eclipse JDT UI project and the
5168 \type{no.uio.ifi.refaktor} project, clearly influenced the differences in their
5169 execution times. This is mostly because fewer of the methods were chosen to be
5170 refactored for the refaktor project than for the JDT project. This makes it
5171 difficult to know if there are any severe performance penalties associated with
5172 refactoring on a large project compared to a small one.
5174 The trends in the \name{SonarQube} analysis are the same for this case as for
5175 the previous one. This gives more confidence in the these results.
5177 By refactoring our own code and using it again to refactor our code, we showed
5178 that it is possible to write an automated composite refactoring that works for
5179 many cases. That it probably did not alter the behavior of a smaller project
5180 shows us nothing more than that though, and might just be a coincidence.
5182 \section{Threats to validity}
5183 \todoin{Tool not fine grained enough.}
5184 \todoin{Only one large project.}
5185 \todoin{Only performing each experiment once. (Performance.)}
5186 \todoin{SonarQube analysis does only show number issues. The overall coupling
5187 may still be lowered.}
5188 \todoin{Could need better metric, like ``the number of references``.}
5191 \chapter{Conclusions and future work}\label{ch:conclusions}
5192 This chapter will conclude this master's thesis. I will try to give justified
5193 answers to the research questions posed \see{sec:researchQuestions} and present
5194 some future work that could be done to take this project to the next level.
5196 \section{Conclusions}
5197 Some of the motivation for this thesis was to create a fully automated composite
5198 refactoring that could be used to make program source code better in terms of
5199 coupling between classes. Earlier, in \mysimpleref{sec:CBO}, it was shown that a
5200 composition of the \ExtractMethod and the \MoveMethod refactorings reduces the
5201 coupling between two classes in an ideal situation. The Eclipse JDT plugin
5202 implements both these refactorings, and also provides a framework for analyzing
5203 source code, so it was considered a suitable tool to build upon for our project.
5205 The search-based \ExtractAndMoveMethod refactoring was created by utilizing the
5206 analysis and refactoring support of Eclipse, and a small framework was built
5207 for executing large scale refactoring with it. The refactoring was set up to
5208 analyze and execute changes on the Eclipse JDT UI project. Statistics was
5209 gathered during this process and the resulting code was analyzed through
5210 SonarQube. The project's own unit tests were also performed to find out whether
5211 our refactoring introduces any behavior-altering changes in the code it
5214 \paragraph{Answering the main research question.}
5215 The first and greatest challenge was to find out if the \ExtractAndMoveMethod
5216 refactoring could be automated, in all tasks ranging from analysis to executing
5217 changes. It is now confirmed that this can be done, since it has been
5218 implemented as a part of the work done for this project. It has also been shown
5219 that the refactoring can be used to refactor large code bases, through the case
5220 study done on the Eclipse JDT UI project.
5222 Asking whether the existing Eclipse refactorings are well suited for this task
5223 is another question. The refactorings provided by the JDT UI project are clearly
5224 not meant to be combined in any way. The preconditions for one refactoring are
5225 not always easily retrievable after the execution of another. Also, the
5226 refactorings are all assuming that the code they are going to refactor is
5227 textualized. This means that the source code must be parsed between the
5228 executions of each refactoring. Another problem with this dependency on textual
5229 changes, is that you cannot make a composition of two refactorings appear as one
5230 change if the two refactorings' changes overlap. This will make the undo-history
5231 of the composite refactoring show two changes instead of one, and is not nice
5232 for usability if the refactoring would be used as an on-demand refactoring in an
5235 Apart from the problems with implementing the actual refactoring, the analysis
5236 framework is quite nicely solved in Eclipse. The AST generated when parsing
5237 source code, supports using visitors to traverse it, and this works without
5240 \paragraph{Is the refactoring efficient enough?}
5241 Since we have concluded that the search-based \ExtractAndMoveMethod refactoring
5242 is not suitable for on-demand large-scale refactoring, but may be put to better
5243 use as a kind of analysis tool, superb performance is not crucial. In
5244 \myref{sec:case1ExecutionTime} we conclude that the refactoring performs well
5245 enough for this purpose. If performed on demand for a single method, the
5246 performance of the \ExtractAndMoveMethod refactoring is not an issue.
5248 \paragraph{What about breaking the source code?}
5249 The case studies shows that our safety measures, which rely on the precondition
5250 checking of the existing primitive refactorings, are not good enough in
5251 practice. If we were going to assure that code we refactor compiles, we would
5252 need to consider all possible situations where the refactoring could fail, and
5253 search for them in our analysis. It is an open question if this is even
5254 feasible. Our analysis is incomplete, and so are the analyses for the
5255 \ExtractMethod and \MoveMethod refactorings.
5257 Our refactoring does not take any precautions to preserve behavior. A few
5258 running and failing unit test for the JDT UI project after the refactoring
5259 indicate that our refactoring causes some changes to the way a program behaves.
5261 \paragraph{Is the quality of the code improved?}
5262 For coupling, there is no evidence that the refactoring improves the quality of
5263 source code. Shall we believe the SonarQube analysis from the case studies, our
5264 refactoring makes classes more coupled after the refactoring than before, in the
5265 general case. Examples exist where the \ExtractAndMoveMethod refactoring
5266 improves coupling. The problem is that it introduces too many dependencies
5267 overall \see{sec:case1IssuesExample}. The essence is that our analysis and
5268 heuristics for finding the best candidates for the refactoring are not adequate.
5270 \paragraph{Is the refactoring useful?}
5271 In its present state, the refactoring cannot be said to be very useful. It
5272 generates too many compilation errors for it to fall into that category. On the
5273 other hand, if the problems with the search-based \ExtractAndMoveMethod
5274 refactoring were to be solved, it could be put to use in some situations.
5276 If the refactoring was perfected, it could of course be used as a regular
5277 on-demand automated refactoring on a per method base (or per class, package or
5280 As it is now, the refactoring is not well suited for performing unattended
5281 refactoring. But if we could find a way to filter out the changes that create
5282 compilation errors, we could use the refactoring to look for improvement points
5283 in a software project. This process could for instance be scheduled to run at
5284 regular intervals, possibly after a nightly build or the like. Then the results
5285 could be made available, and an administrator could be set to review them and
5286 choose whether or not they should be performed.
5288 \section{Future work}
5289 An important part that is missing for making the search-based
5290 \ExtractAndMoveMethod refactoring more usable, is to complete the
5291 pre-refactoring analysis of the source code, to make sure that the refactoring
5292 does not introduce compilation errors when it is performed.
5294 The first point of making the static analysis complete, brings up the next
5295 question: Is it feasible to complete such an analysis? And can this feasibility
5296 be proven, or disproved?
5298 Another shortcoming of this project is that we have no strategy for assuring
5299 safety when refactoring, so a program may end up behaving differently after a
5300 refactoring than it behaved before. One approach toward safer refactorings is
5301 mentioned in \myref{sec:saferRefactoringTests}, and includes generating tests
5302 for the refactored code. Another approach that can be considered for making
5303 refactorings safer is part of the original thesis proposal for this thesis,
5304 which diverged somewhat from the original proposal. The proposal is about
5305 detecting behavioral changes during refactoring, and the work done in this
5306 thesis can be used as a basis if one would like to engage in that proposal. The
5307 proposed solution for exposing behavioral changes, is to insert assertions into
5308 source code when refactoring it. For the example in
5309 \myref{lst:correctnessExtractAndMoveResult}, which is the result of a
5310 refactoring, it is suggested that we insert an assert statement between lines 9
5311 and 10. In the example, the assert statement would be
5312 \mint{java}|assert c.x == this;| which would discover the aliasing problems of
5315 The final important improvement that I would suggest making to this project, is
5316 to refine the heuristics that are used to find suitable refactoring candidates.
5317 This effort should in particular be directed toward making the heuristics choose
5318 candidates that do not introduce new dependencies to their destination classes.
5324 \chapter{Eclipse bugs submitted}
5325 \newcommand{\submittedBugReport}[1]{The submitted bug report can be found on
5328 \section{Eclipse bug 420726: Code is broken when moving a method that is
5329 assigning to the parameter that is also the move
5330 destination}\label{eclipse_bug_420726}
5332 was found when analyzing what kinds of names that were to be considered as
5333 \emph{unfixes} \see{sec:unfixes}.
5335 \paragraph{The bug.}
5336 The bug emerges when trying to move a method from one class to another, and when
5337 the target for the move (must be a variable, local or field) is both a parameter
5338 variable and also is assigned to within the method body. \name{Eclipse} allows this to
5339 happen, although it is the sure path to a compilation error. This is because we
5340 would then have an assignment to a \var{this} expression, which is not allowed
5342 \submittedBugReport{https://bugs.eclipse.org/bugs/show\_bug.cgi?id=420726}
5344 \paragraph{The solution.}
5345 The solution to this problem is to add all simple names that are assigned to in
5346 a method body to the set of unfixes.
5348 \section{Eclipse bug 429416: IAE when moving method from anonymous
5349 class}\label{eclipse_bug_429416}
5351 this bug during a batch change on the \type{org.eclipse.jdt.ui} project.
5353 \paragraph{The bug.}
5354 This bug surfaces when trying to use the \refa{Move Method} refactoring to move a
5355 method from an anonymous class to another class. This happens both for my
5356 simulation as well as in \name{Eclipse}, through the user interface. It only occurs
5357 when \name{Eclipse} analyzes the program and finds it necessary to pass an
5358 instance of the originating class as a parameter to the moved method. I.e. it
5359 wants to pass a \var{this} expression. The execution ends in an
5360 \typewithref{java.lang}{IllegalArgumentException} in
5361 \typewithref{org.eclipse.jdt.core.dom}{SimpleName} and its
5362 \method{setIdentifier(String)} method. The simple name is attempted created in
5364 \methodwithref{org.eclipse.jdt.internal.corext.refactoring.structure.\\MoveInstanceMethodProcessor}{createInlinedMethodInvocation}
5365 so the \type{MoveInstanceMethodProcessor} was early a clear suspect.
5367 The \method{createInlinedMethodInvocation} is the method that creates a method
5368 invocation where the previous invocation to the method that was moved was
5369 located. From its code it can be read that when a \var{this} expression is going
5370 to be passed in to the invocation, it shall be qualified with the name of the
5371 original method's declaring class, if the declaring class is either an anonymous
5372 class or a member class. The problem with this, is that an anonymous class does
5373 not have a name, hence the term \emph{anonymous} class! Therefore, when its
5374 name, an empty string, is passed into
5375 \methodwithref{org.eclipse.jdt.core.dom.AST}{newSimpleName} it all ends in an
5376 \type{IllegalArgumentException}.
5377 \submittedBugReport{https://bugs.eclipse.org/bugs/show\_bug.cgi?id=429416}
5379 \paragraph{How I solved the problem.}
5380 Since the \type{MoveInstanceMethodProcessor} is instantiated in the
5381 \typewithref{no.uio.ifi.refaktor.change.executors}{MoveMethod\-RefactoringExecutor},
5382 and only need to be a
5383 \typewithref{org.eclipse.ltk.core.refactoring.participants}{MoveProcessor}, I
5384 was able to copy the code for the original move processor and modify it so that
5385 it works better for me. It is now called
5386 \typewithref{no.uio.ifi.refaktor.change.processors}{ModifiedMoveInstanceMethodProcessor}.
5387 The only modification done (in addition to some imports and suppression of
5388 warnings), is in the \method{createInlinedMethodInvocation}. When the declaring
5389 class of the method to move is anonymous, the \var{this} expression in the
5390 parameter list is not qualified with the declaring class' (empty) name.
5392 \section{Eclipse bug 429954: Extracting statement with reference to local type
5393 breaks code}\label{eclipse_bug_429954}
5394 The bug was discovered when doing some changes to the way unfixes is computed.
5396 \paragraph{The bug.}
5397 The problem is that \name{Eclipse} is allowing selections that references variables of
5398 local types to be extracted. When this happens the code is broken, since the
5399 extracted method must take a parameter of a local type that is not in the
5400 methods scope. The problem is illustrated in
5401 \myref{lst:extractMethodLocalClass}, but there in another setting.
5402 \submittedBugReport{https://bugs.eclipse.org/bugs/show\_bug.cgi?id=429954}
5404 \paragraph{Actions taken.}
5405 There are no actions directly springing out of this bug, since the Extract
5406 Method refactoring cannot be meant to be this way. This is handled on the
5407 analysis stage of our \refa{Extract and Move Method} refactoring. So names
5408 representing variables of local types are considered unfixes \see{sec:unfixes}.