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
11 \usepackage{tikz-qtree}
12 \usetikzlibrary{shapes,snakes,trees,arrows,shadows,positioning,calc}
13 \usepackage{babel,textcomp,csquotes,ifimasterforside}
16 \usepackage[hidelinks]{hyperref}
18 \usepackage[xindy,entrycounter]{glossaries}
20 \usepackage[style=alphabetic,backend=biber]{biblatex}
22 \usepackage{mathtools}
24 % use 'disable' before printing:
25 \usepackage[]{todonotes}
32 \usepackage{perpage} %the perpage package
33 \MakePerPage{footnote} %the perpage package command
35 \theoremstyle{definition}
36 \newtheorem*{wordDef}{Definition}
37 \newtheorem*{theorem}{Theorem}
39 \graphicspath{ {./figures/} }
41 \newcommand{\citing}[1]{~\cite{#1}}
42 %\newcommand{\myref}[1]{\cref{#1} on \cpageref{#1}}
43 \newcommand{\myref}[1]{\vref{#1}}
45 \newcommand{\glossref}[1]{\textsuperscript{(\glsrefentry{#1})}}
46 %\newcommand{\gloss}[1]{\gls{#1}\glossref{#1}}
47 %\newcommand{\glosspl}[1]{\glspl{#1}\glossref{#1}}
48 \newcommand{\gloss}[1]{\gls{#1}}
49 \newcommand{\glosspl}[1]{\glspl{#1}}
51 \newcommand{\definition}[1]{\begin{wordDef}#1\end{wordDef}}
52 \newcommand{\see}[1]{(see \myref{#1})}
53 \newcommand{\explanation}[3]{\noindent\textbf{\textit{#1}}\\*\emph{When:}
54 #2\\*\emph{How:} #3\\*[-7px]}
56 %\newcommand{\type}[1]{\lstinline{#1}}
57 \newcommand{\code}[1]{\texttt{\textbf{#1}}}
58 \newcommand{\type}[1]{\code{#1}}
59 \newcommand{\typeref}[1]{\footnote{\type{#1}}}
60 \newcommand{\typewithref}[2]{\type{#2}\typeref{#1.#2}}
61 \newcommand{\method}[1]{\type{#1}}
62 \newcommand{\methodref}[2]{\footnote{\type{#1}\method{\##2()}}}
63 \newcommand{\methodwithref}[2]{\method{#2}\footnote{\type{#1}\method{\##2()}}}
64 \newcommand{\var}[1]{\type{#1}}
66 \newcommand{\name}[1]{#1}
67 \newcommand{\tit}[1]{\emph{#1}}
68 \newcommand{\refa}[1]{\emph{#1}}
69 \newcommand{\pattern}[1]{\emph{#1}}
70 \newcommand{\metr}[1]{\emph{#1}}
71 \newcommand{\ExtractMethod}{\refa{Extract Method}\xspace}
72 \newcommand{\MoveMethod}{\refa{Move Method}\xspace}
73 \newcommand{\ExtractAndMoveMethod}{\refa{Extract and Move Method}\xspace}
75 \newcommand\todoin[2][]{\todo[inline, caption={#2}, #1]{
76 \begin{minipage}{\textwidth-4pt}#2\end{minipage}}}
78 \title{Automated Composition of Refactorings}
79 \subtitle{Composing the Extract and Move Method refactorings in Eclipse}
80 \author{Erlend Kristiansen}
83 \newglossaryentry{profiling}
86 description={is to run a computer program through a profiler/with a profiler
89 \newglossaryentry{profiler}
92 description={A profiler is a program for analyzing performance within an
93 application. It is used to analyze memory consumption, processing time and
94 frequency of procedure calls and such.}
96 \newglossaryentry{xUnit}
98 name={xUnit framework},
99 description={An xUnit framework is a framework for writing unit tests for a
100 computer program. It follows the patterns known from the JUnit framework for
101 Java\citing{fowlerXunit}
103 plural={xUnit frameworks}
105 \newglossaryentry{softwareObfuscation}
107 name={software obfuscation},
108 description={makes source code harder to read and analyze, while preserving
111 \newglossaryentry{extractClass}
113 name=\refa{Extract Class},
114 description={The \refa{Extract Class} refactoring works by creating a class,
115 for then to move members from another class to that class and access them from
116 the old class via a reference to the new class}
118 \newglossaryentry{designPattern}
120 name={design pattern},
121 description={A design pattern is a named abstraction, that is meant to solve a
122 general design problem. It describes the key aspects of a common problem and
123 identifies its participators and how they collaborate},
124 plural={design patterns}
126 \newglossaryentry{extractMethod}
128 name=\refa{Extract Method},
129 description={The \refa{Extract Method} refactoring is used to extract a
130 fragment of code from its context and into a new method. A call to the new
131 method is inlined where the fragment was before. It is used to break code into
132 logical units, with names that explain their purpose}
134 \newglossaryentry{moveMethod}
136 name=\refa{Move Method},
137 description={The \refa{Move Method} refactoring is used to move a method from
138 one class to another. This is useful if the method is using more features of
139 another class than of the class which it is currently defined. Then all calls
140 to this method must be updated, or the method must be copied, with the old
141 method delegating to the new method}
144 \bibliography{bibliography/master-thesis-erlenkr-bibliography}
146 % UML comment in TikZ:
147 % ref: https://tex.stackexchange.com/questions/103688/folded-paper-shape-tikz
149 \pgfdeclareshape{umlcomment}{
150 \inheritsavedanchors[from=rectangle] % this is nearly a rectangle
151 \inheritanchorborder[from=rectangle]
152 \inheritanchor[from=rectangle]{center}
153 \inheritanchor[from=rectangle]{north}
154 \inheritanchor[from=rectangle]{south}
155 \inheritanchor[from=rectangle]{west}
156 \inheritanchor[from=rectangle]{east}
157 % ... and possibly more
158 \backgroundpath{% this is new
159 % store lower right in xa/ya and upper right in xb/yb
160 \southwest \pgf@xa=\pgf@x \pgf@ya=\pgf@y
161 \northeast \pgf@xb=\pgf@x \pgf@yb=\pgf@y
162 % compute corner of ‘‘flipped page’’
163 \pgf@xc=\pgf@xb \advance\pgf@xc by-10pt % this should be a parameter
164 \pgf@yc=\pgf@yb \advance\pgf@yc by-10pt
165 % construct main path
166 \pgfpathmoveto{\pgfpoint{\pgf@xa}{\pgf@ya}}
167 \pgfpathlineto{\pgfpoint{\pgf@xa}{\pgf@yb}}
168 \pgfpathlineto{\pgfpoint{\pgf@xc}{\pgf@yb}}
169 \pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@yc}}
170 \pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@ya}}
173 \pgfpathmoveto{\pgfpoint{\pgf@xc}{\pgf@yb}}
174 \pgfpathlineto{\pgfpoint{\pgf@xc}{\pgf@yc}}
175 \pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@yc}}
176 \pgfpathlineto{\pgfpoint{\pgf@xc}{\pgf@yc}}
181 \tikzstyle{comment}=[%
194 %\interfootnotelinepenalty=10000
197 \pagenumbering{roman}
203 \todoin{\textbf{Remove all todos (including list) before delivery/printing!!!
204 Can be done by removing ``draft'' from documentclass.}}
205 \todoin{Write abstract}
213 The discussions in this report must be seen in the context of object oriented
214 programming languages, and Java in particular, since that is the language in
215 which most of the examples will be given. All though the techniques discussed
216 may be applicable to languages from other paradigms, they will not be the
217 subject of this report.
221 \chapter{What is Refactoring?}
223 This question is best answered by first defining the concept of a
224 \emph{refactoring}, what it is to \emph{refactor}, and then discuss what aspects
225 of programming make people want to refactor their code.
227 \section{Defining refactoring}
228 Martin Fowler, in his classic book on refactoring\citing{refactoring}, defines a
229 refactoring like this:
232 \emph{Refactoring} (noun): a change made to the internal
233 structure\footnote{The structure observable by the programmer.} of software to
234 make it easier to understand and cheaper to modify without changing its
235 observable behavior.~\cite[p.~53]{refactoring}
238 \noindent This definition assigns additional meaning to the word
239 \emph{refactoring}, beyond the composition of the prefix \emph{re-}, usually
240 meaning something like ``again'' or ``anew'', and the word \emph{factoring},
241 that can mean to isolate the \emph{factors} of something. Here a \emph{factor}
242 would be close to the mathematical definition of something that divides a
243 quantity, without leaving a remainder. Fowler is mixing the \emph{motivation}
244 behind refactoring into his definition. Instead it could be more refined, formed
245 to only consider the \emph{mechanical} and \emph{behavioral} aspects of
246 refactoring. That is to factor the program again, putting it together in a
247 different way than before, while preserving the behavior of the program. An
248 alternative definition could then be:
250 \definition{A \emph{refactoring} is a transformation
251 done to a program without altering its external behavior.}
253 From this we can conclude that a refactoring primarily changes how the
254 \emph{code} of a program is perceived by the \emph{programmer}, and not the
255 \emph{behavior} experienced by any user of the program. Although the logical
256 meaning is preserved, such changes could potentially alter the program's
257 behavior when it comes to performance gain or -penalties. So any logic depending
258 on the performance of a program could make the program behave differently after
261 In the extreme case one could argue that \gloss{softwareObfuscation} is
262 refactoring. It is often used to protect proprietary software. It restrains
263 uninvited viewers, so they have a hard time analyzing code that they are not
264 supposed to know how works. This could be a problem when using a language that
265 is possible to decompile, such as Java.
267 Obfuscation could be done composing many, more or less randomly chosen,
268 refactorings. Then the question arises whether it can be called a
269 \emph{composite refactoring} or not \see{compositeRefactorings}? The answer is
270 not obvious. First, there is no way to describe the mechanics of software
271 obfuscation, because there are infinitely many ways to do that. Second,
272 obfuscation can be thought of as \emph{one operation}: Either the code is
273 obfuscated, or it is not. Third, it makes no sense to call software obfuscation
274 \emph{a refactoring}, since it holds different meaning to different people.
276 This last point is important, since one of the motivations behind defining
277 different refactorings, is to establish a \emph{vocabulary} for software
278 professionals to use when reasoning about and discussing programs, similar to
279 the motivation behind \glosspl{designPattern}\citing{designPatterns}.
281 So for describing \emph{software obfuscation}, it might be more appropriate to
282 define what you do when performing it rather than precisely defining its
283 mechanics in terms of other refactorings.
286 \section{The etymology of 'refactoring'}
287 It is a little difficult to pinpoint the exact origin of the word
288 ``refactoring'', as it seems to have evolved as part of a colloquial
289 terminology, more than a scientific term. There is no authoritative source for a
290 formal definition of it.
292 According to Martin Fowler\citing{etymology-refactoring}, there may also be more
293 than one origin of the word. The most well-known source, when it comes to the
294 origin of \emph{refactoring}, is the
295 Smalltalk\footnote{\label{footNote}Programming language} community and their
296 infamous \name{Refactoring
297 Browser}\footnote{\url{http://st-www.cs.illinois.edu/users/brant/Refactory/RefactoringBrowser.html}}
298 described in the article \tit{A Refactoring Tool for
299 Smalltalk}\citing{refactoringBrowser1997}, published in 1997.
300 Allegedly\citing{etymology-refactoring}, the metaphor of factoring programs was
301 also present in the Forth\textsuperscript{\ref{footNote}} community, and the
302 word ``refactoring'' is mentioned in a book by Leo Brodie, called \tit{Thinking
303 Forth}\citing{brodie2004}, first published in 1984\footnote{\tit{Thinking Forth}
304 was first published in 1984 by the \name{Forth Interest Group}. Then it was
305 reprinted in 1994 with minor typographical corrections, before it was
306 transcribed into an electronic edition typeset in \LaTeX\ and published under a
307 Creative Commons licence in
308 2004. The edition cited here is the 2004 edition, but the content should
309 essentially be as in 1984.}. The exact word is only printed one
310 place~\cite[p.~232]{brodie2004}, but the term \emph{factoring} is prominent in
311 the book, that also contains a whole chapter dedicated to (re)factoring, and how
312 to keep the (Forth) code clean and maintainable.
315 \ldots good factoring technique is perhaps the most important skill for a
316 Forth programmer.~\cite[p.~172]{brodie2004}
319 \noindent Brodie also express what \emph{factoring} means to him:
322 Factoring means organizing code into useful fragments. To make a fragment
323 useful, you often must separate reusable parts from non-reusable parts. The
324 reusable parts become new definitions. The non-reusable parts become arguments
325 or parameters to the definitions.~\cite[p.~172]{brodie2004}
328 Fowler claims that the usage of the word \emph{refactoring} did not pass between
329 the \name{Forth} and \name{Smalltalk} communities, but that it emerged
330 independently in each of the communities.
332 \section{Motivation -- Why people refactor}
333 There are many reasons why people want to refactor their programs. They can for
334 instance do it to remove duplication, break up long methods or to introduce
335 design patterns into their software systems. The shared trait for all these are
336 that peoples' intentions are to make their programs \emph{better}, in some
337 sense. But what aspects of their programs are becoming improved?
339 As just mentioned, people often refactor to get rid of duplication. They are
340 moving identical or similar code into methods, and are pushing methods up or
341 down in their class hierarchies. They are making template methods for
342 overlapping algorithms/functionality, and so on. It is all about gathering what
343 belongs together and putting it all in one place. The resulting code is then
344 easier to maintain. When removing the implicit coupling\footnote{When
345 duplicating code, the duplicate pieces of code might not be coupled, apart
346 from representing the same functionality. So if this functionality is going to
347 change, it might need to change in more than one place, thus creating an
348 implicit coupling between multiple pieces of code.} between code snippets, the
349 location of a bug is limited to only one place, and new functionality need only
350 to be added to this one place, instead of a number of places people might not
353 A problem you often encounter when programming, is that a program contains a lot
354 of long and hard-to-grasp methods. It can then help to break the methods into
355 smaller ones, using the \gloss{extractMethod} refactoring\citing{refactoring}.
356 Then you may discover something about a program that you were not aware of
357 before; revealing bugs you did not know about or could not find due to the
358 complex structure of your program. \todo{Proof?} Making the methods smaller and
359 giving good names to the new ones clarifies the algorithms and enhances the
360 \emph{understandability} of the program \see{magic_number_seven}. This makes
361 refactoring an excellent method for exploring unknown program code, or code that
362 you had forgotten that you wrote.
364 Most primitive refactorings are simple, and usually involves moving code
365 around\citing{kerievsky2005}. The motivation behind them may first be revealed
366 when they are combined into larger --- higher level --- refactorings, called
367 \emph{composite refactorings} \see{compositeRefactorings}. Often the goal of
368 such a series of refactorings is a design pattern. Thus the design can
369 \emph{evolve} throughout the lifetime of a program, as opposed to designing
370 up-front. It is all about being structured and taking small steps to improve a
373 Many software design pattern are aimed at lowering the coupling between
374 different classes and different layers of logic. One of the most famous is
375 perhaps the \pattern{Model-View-Controller}\citing{designPatterns} pattern. It
376 is aimed at lowering the coupling between the user interface, the business logic
377 and the data representation of a program. This also has the added benefit that
378 the business logic could much easier be the target of automated tests, thus
379 increasing the productivity in the software development process.
381 Another effect of refactoring is that with the increased separation of concerns
382 coming out of many refactorings, the \emph{performance} can be improved. When
383 profiling programs, the problematic parts are narrowed down to smaller parts of
384 the code, which are easier to tune, and optimization can be performed only where
385 needed and in a more effective way\citing{refactoring}.
387 Last, but not least, and this should probably be the best reason to refactor, is
388 to refactor to \emph{facilitate a program change}. If one has managed to keep
389 one's code clean and tidy, and the code is not bloated with design patterns that
390 are not ever going to be needed, then some refactoring might be needed to
391 introduce a design pattern that is appropriate for the change that is going to
394 Refactoring program code --- with a goal in mind --- can give the code itself
395 more value. That is in the form of robustness to bugs, understandability and
396 maintainability. Having robust code is an obvious advantage, but
397 understandability and maintainability are both very important aspects of
398 software development. By incorporating refactoring in the development process,
399 bugs are found faster, new functionality is added more easily and code is easier
400 to understand by the next person exposed to it, which might as well be the
401 person who wrote it. The consequence of this, is that refactoring can increase
402 the average productivity of the development process, and thus also add to the
403 monetary value of a business in the long run. The perspective on productivity
404 and money should also be able to open the eyes of the many nearsighted managers
405 that seldom see beyond the next milestone.
407 \section{The magical number seven}\label{magic_number_seven}
408 The article \tit{The magical number seven, plus or minus two: some limits on our
409 capacity for processing information}\citing{miller1956} by George A. Miller,
410 was published in the journal \name{Psychological Review} in 1956. It presents
411 evidence that support that the capacity of the number of objects a human being
412 can hold in its working memory is roughly seven, plus or minus two objects. This
413 number varies a bit depending on the nature and complexity of the objects, but
414 is according to Miller ``\ldots never changing so much as to be
417 Miller's article culminates in the section called \emph{Recoding}, a term he
418 borrows from communication theory. The central result in this section is that by
419 recoding information, the capacity of the amount of information that a human can
420 process at a time is increased. By \emph{recoding}, Miller means to group
421 objects together in chunks, and give each chunk a new name that it can be
425 \ldots recoding is an extremely powerful weapon for increasing the amount of
426 information that we can deal with.~\cite[p.~95]{miller1956}
429 By organizing objects into patterns of ever growing depth, one can memorize and
430 process a much larger amount of data than if it were to be represented as its
431 basic pieces. This grouping and renaming is analogous to how many refactorings
432 work, by grouping pieces of code and give them a new name. Examples are the
433 fundamental \ExtractMethod and \refa{Extract Class}
434 refactorings\citing{refactoring}.
436 An example from the article addresses the problem of memorizing a sequence of
437 binary digits. The example presented here is a slightly modified version of the
438 one presented in the original article\citing{miller1956}, but it preserves the
439 essence of it. Let us say we have the following sequence of
440 16 binary digits: ``1010001001110011''. Most of us will have a hard time
441 memorizing this sequence by only reading it once or twice. Imagine if we instead
442 translate it to this sequence: ``A273''. If you have a background from computer
443 science, it will be obvious that the latter sequence is the first sequence
444 recoded to be represented by digits in base 16. Most people should be able to
445 memorize this last sequence by only looking at it once.
447 Another result from the Miller article is that when the amount of information a
448 human must interpret increases, it is crucial that the translation from one code
449 to another must be almost automatic for the subject to be able to remember the
450 translation, before \heshe is presented with new information to recode. Thus
451 learning and understanding how to best organize certain kinds of data is
452 essential to efficiently handle that kind of data in the future. This is much
453 like when humans learn to read. First they must learn how to recognize letters.
454 Then they can learn distinct words, and later read sequences of words that form
455 whole sentences. Eventually, most of them will be able to read whole books and
456 briefly retell the important parts of its content. This suggest that the use of
457 design patterns is a good idea when reasoning about computer programs. With
458 extensive use of design patterns when creating complex program structures, one
459 does not always have to read whole classes of code to comprehend how they
460 function, it may be sufficient to only see the name of a class to almost fully
461 understand its responsibilities.
464 Our language is tremendously useful for repackaging material into a few chunks
465 rich in information.~\cite[p.~95]{miller1956}
468 Without further evidence, these results at least indicate that refactoring
469 source code into smaller units with higher cohesion and, when needed,
470 introducing appropriate design patterns, should aid in the cause of creating
471 computer programs that are easier to maintain and have code that is easier (and
474 \section{Notable contributions to the refactoring literature}
475 \todoin{Thinking Forth?}
478 \item[1992] William F. Opdyke submits his doctoral dissertation called
479 \tit{Refactoring Object-Oriented Frameworks}\citing{opdyke1992}. This work
480 defines a set of refactorings, that are behavior preserving given that their
481 preconditions are met. The dissertation is focused on the automation of
483 \item[1999] Martin Fowler et al.: \tit{Refactoring: Improving the Design of
484 Existing Code}\citing{refactoring}. This is maybe the most influential text
485 on refactoring. It bares similarities with Opdykes thesis\citing{opdyke1992}
486 in the way that it provides a catalog of refactorings. But Fowler's book is
487 more about the craft of refactoring, as he focuses on establishing a
488 vocabulary for refactoring, together with the mechanics of different
489 refactorings and when to perform them. His methodology is also founded on
490 the principles of test-driven development.
491 \item[2005] Joshua Kerievsky: \tit{Refactoring to
492 Patterns}\citing{kerievsky2005}. This book is heavily influenced by Fowler's
493 \tit{Refactoring}\citing{refactoring} and the ``Gang of Four'' \tit{Design
494 Patterns}\citing{designPatterns}. It is building on the refactoring
495 catalogue from Fowler's book, but is trying to bridge the gap between
496 \emph{refactoring} and \emph{design patterns} by providing a series of
497 higher-level composite refactorings, that makes code evolve toward or away
498 from certain design patterns. The book is trying to build up the reader's
499 intuition around \emph{why} one would want to use a particular design
500 pattern, and not just \emph{how}. The book is encouraging evolutionary
501 design \see{relationToDesignPatterns}.
504 \section{Tool support (for Java)}\label{toolSupport}
505 This section will briefly compare the refactoring support of the three IDEs
506 \name{Eclipse}\footnote{\url{http://www.eclipse.org/}}, \name{IntelliJ
507 IDEA}\footnote{The IDE under comparison is the \name{Community Edition},
508 \url{http://www.jetbrains.com/idea/}} and
509 \name{NetBeans}\footnote{\url{https://netbeans.org/}}. These are the most
510 popular Java IDEs\citing{javaReport2011}.
512 All three IDEs provide support for the most useful refactorings, like the
513 different extract, move and rename refactorings. In fact, Java-targeted IDEs are
514 known for their good refactoring support, so this did not appear as a big
517 The IDEs seem to have excellent support for the \ExtractMethod refactoring, so
518 at least they have all passed the first ``refactoring
519 rubicon''\citing{fowlerRubicon2001,secondRubicon2012}.
521 Regarding the \gloss{moveMethod} refactoring, the \name{Eclipse} and
522 \name{IntelliJ} IDEs do the job in very similar manners. In most situations they
523 both do a satisfying job by producing the expected outcome. But they do nothing
524 to check that the result does not break the semantics of the program
526 The \name{NetBeans} IDE implements this refactoring in a somewhat
527 unsophisticated way. For starters, the refactoring's default destination for the
528 move, is the same class as the method already resides in, although it refuses to
529 perform the refactoring if chosen. But the worst part is, that if moving the
530 method \method{f} of the class \type{C} to the class \type{X}, it will break the
531 code. The result is shown in \myref{lst:moveMethod_NetBeans}.
535 \begin{minted}[samepage]{java}
548 \begin{minted}[samepage]{java}
558 \caption{Moving method \method{f} from \type{C} to \type{X}.}
559 \label{lst:moveMethod_NetBeans}
562 \name{NetBeans} will try to create code that call the methods \method{m} and \method{n}
563 of \type{X} by accessing them through \var{c.x}, where \var{c} is a parameter of
564 type \type{C} that is added the method \method{f} when it is moved. (This is
565 seldom the desired outcome of this refactoring, but ironically, this ``feature''
566 keeps \name{NetBeans} from breaking the code in the example from \myref{correctness}.)
567 If \var{c.x} for some reason is inaccessible to \type{X}, as in this case, the
568 refactoring breaks the code, and it will not compile. \name{NetBeans} presents a
569 preview of the refactoring outcome, but the preview does not catch it if the IDE
570 is about break the program.
572 The IDEs under investigation seem to have fairly good support for primitive
573 refactorings, but what about more complex ones, such as
574 \gloss{extractClass}\citing{refactoring}? \name{IntelliJ} handles this in a
575 fairly good manner, although, in the case of private methods, it leaves unused
576 methods behind. These are methods that delegate to a field with the type of the
577 new class, but are not used anywhere. \name{Eclipse} has added its own quirk to
578 the \refa{Extract Class} refactoring, and only allows for \emph{fields} to be
579 moved to a new class, \emph{not methods}. This makes it effectively only
580 extracting a data structure, and calling it \refa{Extract Class} is a little
581 misleading. One would often be better off with textual extract and paste than
582 using the \refa{Extract Class} refactoring in \name{Eclipse}. When it comes to
583 \name{NetBeans}, it does not even show an attempt on providing this refactoring.
585 \section{The relation to design patterns}\label{relationToDesignPatterns}
587 Refactoring and design patterns have at least one thing in common, they are both
588 promoted by advocates of \emph{clean code}\citing{cleanCode} as fundamental
589 tools on the road to more maintainable and extendable source code.
592 Design patterns help you determine how to reorganize a design, and they can
593 reduce the amount of refactoring you need to do
594 later.~\cite[p.~353]{designPatterns}
597 Although sometimes associated with
598 over-engineering\citing{kerievsky2005,refactoring}, design patterns are in
599 general assumed to be good for maintainability of source code. That may be
600 because many of them are designed to support the \emph{open/closed principle} of
601 object-oriented programming. The principle was first formulated by Bertrand
602 Meyer, the creator of the Eiffel programming language, like this: ``Modules
603 should be both open and closed.''\citing{meyer1988} It has been popularized,
604 with this as a common version:
607 Software entities (classes, modules, functions, etc.) should be open for
608 extension, but closed for modification.\footnote{See
609 \url{http://c2.com/cgi/wiki?OpenClosedPrinciple} or
610 \url{https://en.wikipedia.org/wiki/Open/closed_principle}}
613 Maintainability is often thought of as the ability to be able to introduce new
614 functionality without having to change too much of the old code. When
615 refactoring, the motivation is often to facilitate adding new functionality. It
616 is about factoring the old code in a way that makes the new functionality being
617 able to benefit from the functionality already residing in a software system,
618 without having to copy old code into new. Then, next time someone shall add new
619 functionality, it is less likely that the old code has to change. Assuming that
620 a design pattern is the best way to get rid of duplication and assist in
621 implementing new functionality, it is reasonable to conclude that a design
622 pattern often is the target of a series of refactorings. Having a repertoire of
623 design patterns can also help in knowing when and how to refactor a program to
624 make it reflect certain desired characteristics.
627 There is a natural relation between patterns and refactorings. Patterns are
628 where you want to be; refactorings are ways to get there from somewhere
629 else.~\cite[p.~107]{refactoring}
632 This quote is wise in many contexts, but it is not always appropriate to say
633 ``Patterns are where you want to be\ldots''. \emph{Sometimes}, patterns are
634 where you want to be, but only because it will benefit your design. It is not
635 true that one should always try to incorporate as many design patterns as
636 possible into a program. It is not like they have intrinsic value. They only add
637 value to a system when they support its design. Otherwise, the use of design
638 patterns may only lead to a program that is more complex than necessary.
641 The overuse of patterns tends to result from being patterns happy. We are
642 \emph{patterns happy} when we become so enamored of patterns that we simply
643 must use them in our code.~\cite[p.~24]{kerievsky2005}
646 This can easily happen when relying largely on up-front design. Then it is
647 natural, in the very beginning, to try to build in all the flexibility that one
648 believes will be necessary throughout the lifetime of a software system.
649 According to Joshua Kerievsky ``That sounds reasonable --- if you happen to be
650 psychic.''~\cite[p.~1]{kerievsky2005} He is advocating what he believes is a
651 better approach: To let software continually evolve. To start with a simple
652 design that meets today's needs, and tackle future needs by refactoring to
653 satisfy them. He believes that this is a more economic approach than investing
654 time and money into a design that inevitably is going to change. By relying on
655 continuously refactoring a system, its design can be made simpler without
656 sacrificing flexibility. To be able to fully rely on this approach, it is of
657 utter importance to have a reliable suit of tests to lean on \see{testing}. This
658 makes the design process more natural and less characterized by difficult
659 decisions that has to be made before proceeding in the process, and that is
660 going to define a project for all of its unforeseeable future.
664 \section{Classification of refactorings}
665 % only interesting refactorings
666 % with 2 detailed examples? One for structured and one for intra-method?
667 % Is replacing Bubblesort with Quick Sort considered a refactoring?
669 \subsection{Structural refactorings}
671 \subsubsection{Primitive refactorings}
674 \explanation{Extract Method}{You have a code fragment that can be grouped
675 together.}{Turn the fragment into a method whose name explains the purpose of
678 \explanation{Inline Method}{A method's body is just as clear as its name.}{Put
679 the method's body into the body of its callers and remove the method.}
681 \explanation{Inline Temp}{You have a temp that is assigned to once with a simple
682 expression, and the temp is getting in the way of other refactorings.}{Replace
683 all references to that temp with the expression}
685 % Moving Features Between Objects
686 \explanation{Move Method}{A method is, or will be, using or used by more
687 features of another class than the class on which it is defined.}{Create a new
688 method with a similar body in the class it uses most. Either turn the old method
689 into a simple delegation, or remove it altogether.}
691 \explanation{Move Field}{A field is, or will be, used by another class more than
692 the class on which it is defined}{Create a new field in the target class, and
693 change all its users.}
696 \explanation{Replace Magic Number with Symbolic Constant}{You have a literal
697 number with a particular meaning.}{Create a constant, name it after the meaning,
698 and replace the number with it.}
700 \explanation{Encapsulate Field}{There is a public field.}{Make it private and
703 \explanation{Replace Type Code with Class}{A class has a numeric type code that
704 does not affect its behavior.}{Replace the number with a new class.}
706 \explanation{Replace Type Code with Subclasses}{You have an immutable type code
707 that affects the behavior of a class.}{Replace the type code with subclasses.}
709 \explanation{Replace Type Code with State/Strategy}{You have a type code that
710 affects the behavior of a class, but you cannot use subclassing.}{Replace the
711 type code with a state object.}
713 % Simplifying Conditional Expressions
714 \explanation{Consolidate Duplicate Conditional Fragments}{The same fragment of
715 code is in all branches of a conditional expression.}{Move it outside of the
718 \explanation{Remove Control Flag}{You have a variable that is acting as a
719 control flag fro a series of boolean expressions.}{Use a break or return
722 \explanation{Replace Nested Conditional with Guard Clauses}{A method has
723 conditional behavior that does not make clear the normal path of
724 execution.}{Use guard clauses for all special cases.}
726 \explanation{Introduce Null Object}{You have repeated checks for a null
727 value.}{Replace the null value with a null object.}
729 \explanation{Introduce Assertion}{A section of code assumes something about the
730 state of the program.}{Make the assumption explicit with an assertion.}
732 % Making Method Calls Simpler
733 \explanation{Rename Method}{The name of a method does not reveal its
734 purpose.}{Change the name of the method}
736 \explanation{Add Parameter}{A method needs more information from its
737 caller.}{Add a parameter for an object that can pass on this information.}
739 \explanation{Remove Parameter}{A parameter is no longer used by the method
742 %\explanation{Parameterize Method}{Several methods do similar things but with
743 %different values contained in the method.}{Create one method that uses a
744 %parameter for the different values.}
746 \explanation{Preserve Whole Object}{You are getting several values from an
747 object and passing these values as parameters in a method call.}{Send the whole
750 \explanation{Remove Setting Method}{A field should be set at creation time and
751 never altered.}{Remove any setting method for that field.}
753 \explanation{Hide Method}{A method is not used by any other class.}{Make the
756 \explanation{Replace Constructor with Factory Method}{You want to do more than
757 simple construction when you create an object}{Replace the constructor with a
760 % Dealing with Generalization
761 \explanation{Pull Up Field}{Two subclasses have the same field.}{Move the field
764 \explanation{Pull Up Method}{You have methods with identical results on
765 subclasses.}{Move them to the superclass.}
767 \explanation{Push Down Method}{Behavior on a superclass is relevant only for
768 some of its subclasses.}{Move it to those subclasses.}
770 \explanation{Push Down Field}{A field is used only by some subclasses.}{Move the
771 field to those subclasses}
773 \explanation{Extract Interface}{Several clients use the same subset of a class's
774 interface, or two classes have part of their interfaces in common.}{Extract the
775 subset into an interface.}
777 \explanation{Replace Inheritance with Delegation}{A subclass uses only part of a
778 superclasses interface or does not want to inherit data.}{Create a field for the
779 superclass, adjust methods to delegate to the superclass, and remove the
782 \explanation{Replace Delegation with Inheritance}{You're using delegation and
783 are often writing many simple delegations for the entire interface}{Make the
784 delegating class a subclass of the delegate.}
786 \subsubsection{Composite refactorings}
789 % \explanation{Replace Method with Method Object}{}{}
791 % Moving Features Between Objects
792 \explanation{Extract Class}{You have one class doing work that should be done by
793 two}{Create a new class and move the relevant fields and methods from the old
794 class into the new class.}
796 \explanation{Inline Class}{A class isn't doing very much.}{Move all its features
797 into another class and delete it.}
799 \explanation{Hide Delegate}{A client is calling a delegate class of an
800 object.}{Create Methods on the server to hide the delegate.}
802 \explanation{Remove Middle Man}{A class is doing to much simple delegation.}{Get
803 the client to call the delegate directly.}
806 \explanation{Replace Data Value with Object}{You have a data item that needs
807 additional data or behavior.}{Turn the data item into an object.}
809 \explanation{Change Value to Reference}{You have a class with many equal
810 instances that you want to replace with a single object.}{Turn the object into a
813 \explanation{Encapsulate Collection}{A method returns a collection}{Make it
814 return a read-only view and provide add/remove methods.}
816 % \explanation{Replace Array with Object}{}{}
818 \explanation{Replace Subclass with Fields}{You have subclasses that vary only in
819 methods that return constant data.}{Change the methods to superclass fields and
820 eliminate the subclasses.}
822 % Simplifying Conditional Expressions
823 \explanation{Decompose Conditional}{You have a complicated conditional
824 (if-then-else) statement.}{Extract methods from the condition, then part, an
827 \explanation{Consolidate Conditional Expression}{You have a sequence of
828 conditional tests with the same result.}{Combine them into a single conditional
829 expression and extract it.}
831 \explanation{Replace Conditional with Polymorphism}{You have a conditional that
832 chooses different behavior depending on the type of an object.}{Move each leg
833 of the conditional to an overriding method in a subclass. Make the original
836 % Making Method Calls Simpler
837 \explanation{Replace Parameter with Method}{An object invokes a method, then
838 passes the result as a parameter for a method. The receiver can also invoke this
839 method.}{Remove the parameter and let the receiver invoke the method.}
841 \explanation{Introduce Parameter Object}{You have a group of parameters that
842 naturally go together.}{Replace them with an object.}
844 % Dealing with Generalization
845 \explanation{Extract Subclass}{A class has features that are used only in some
846 instances.}{Create a subclass for that subset of features.}
848 \explanation{Extract Superclass}{You have two classes with similar
849 features.}{Create a superclass and move the common features to the
852 \explanation{Collapse Hierarchy}{A superclass and subclass are not very
853 different.}{Merge them together.}
855 \explanation{Form Template Method}{You have two methods in subclasses that
856 perform similar steps in the same order, yet the steps are different.}{Get the
857 steps into methods with the same signature, so that the original methods become
858 the same. Then you can pull them up.}
861 \subsection{Functional refactorings}
863 \explanation{Substitute Algorithm}{You want to replace an algorithm with one
864 that is clearer.}{Replace the body of the method with the new algorithm.}
868 \section{The impact on software quality}
870 \subsection{What is software quality?}
871 The term \emph{software quality} has many meanings. It all depends on the
872 context we put it in. If we look at it with the eyes of a software developer, it
873 usually means that the software is easily maintainable and testable, or in other
874 words, that it is \emph{well designed}. This often correlates with the
875 management scale, where \emph{keeping the schedule} and \emph{customer
876 satisfaction} is at the center. From the customers point of view, in addition to
877 good usability, \emph{performance} and \emph{lack of bugs} is always
878 appreciated, measurements that are also shared by the software developer. (In
879 addition, such things as good documentation could be measured, but this is out
880 of the scope of this document.)
882 \subsection{The impact on performance}
884 Refactoring certainly will make software go more slowly\footnote{With todays
885 compiler optimization techniques and performance tuning of e.g. the Java
886 virtual machine, the penalties of object creation and method calls are
887 debatable.}, but it also makes the software more amenable to performance
888 tuning.~\cite[p.~69]{refactoring}
891 \noindent There is a common belief that refactoring compromises performance, due
892 to increased degree of indirection and that polymorphism is slower than
895 In a survey, Demeyer\citing{demeyer2002} disproves this view in the case of
896 polymorphism. He did an experiment on, what he calls, ``Transform Self Type
897 Checks'' where you introduce a new polymorphic method and a new class hierarchy
898 to get rid of a class' type checking of a ``type attribute``. He uses this kind
899 of transformation to represent other ways of replacing conditionals with
900 polymorphism as well. The experiment is performed on the C++ programming
901 language and with three different compilers and platforms. Demeyer concludes
902 that, with compiler optimization turned on, polymorphism beats middle to large
903 sized if-statements and does as well as case-statements. (In accordance with
904 his hypothesis, due to similarities between the way C++ handles polymorphism and
908 The interesting thing about performance is that if you analyze most programs,
909 you find that they waste most of their time in a small fraction of the
910 code.~\cite[p.~70]{refactoring}
913 \noindent So, although an increased amount of method calls could potentially
914 slow down programs, one should avoid premature optimization and sacrificing good
915 design, leaving the performance tuning until after \gloss{profiling} the
916 software and having isolated the actual problem areas.
918 \section{Composite refactorings}\label{compositeRefactorings}
919 \todo{motivation, examples, manual vs automated?, what about refactoring in a
920 very large code base?}
921 Generally, when thinking about refactoring, at the mechanical level, there are
922 essentially two kinds of refactorings. There are the \emph{primitive}
923 refactorings, and the \emph{composite} refactorings.
925 \definition{A \emph{primitive refactoring} is a refactoring that cannot be
926 expressed in terms of other refactorings.}
928 \noindent Examples are the \refa{Pull Up Field} and \refa{Pull Up
929 Method} refactorings\citing{refactoring}, that move members up in their class
932 \definition{A \emph{composite refactoring} is a refactoring that can be
933 expressed in terms of two or more other refactorings.}
935 \noindent An example of a composite refactoring is the \refa{Extract
936 Superclass} refactoring\citing{refactoring}. In its simplest form, it is composed
937 of the previously described primitive refactorings, in addition to the
938 \refa{Pull Up Constructor Body} refactoring\citing{refactoring}. It works
939 by creating an abstract superclass that the target class(es) inherits from, then
940 by applying \refa{Pull Up Field}, \refa{Pull Up Method} and
941 \refa{Pull Up Constructor Body} on the members that are to be members of
942 the new superclass. If there are multiple classes in play, their interfaces may
943 need to be united with the help of some rename refactorings, before extracting
944 the superclass. For an overview of the \refa{Extract Superclass}
945 refactoring, see \myref{fig:extractSuperclass}.
949 \includegraphics[angle=270,width=\linewidth]{extractSuperclassItalic.pdf}
950 \caption{The Extract Superclass refactoring, with united interfaces.}
951 \label{fig:extractSuperclass}
954 \section{Manual vs. automated refactorings}
955 Refactoring is something every programmer does, even if \heshe does not known
956 the term \emph{refactoring}. Every refinement of source code that does not alter
957 the program's behavior is a refactoring. For small refactorings, such as
958 \ExtractMethod, executing it manually is a manageable task, but is still prone
959 to errors. Getting it right the first time is not easy, considering the method
960 signature and all the other aspects of the refactoring that has to be in place.
962 Consider the renaming of classes, methods and fields. For complex programs these
963 refactorings are almost impossible to get right. Attacking them with textual
964 search and replace, or even regular expressions, will fall short on these tasks.
965 Then it is crucial to have proper tool support that can perform them
966 automatically. Tools that can parse source code and thus have semantic knowledge
967 about which occurrences of which names belong to what construct in the program.
968 For even trying to perform one of these complex task manually, one would have to
969 be very confident on the existing test suite \see{testing}.
971 \section{Correctness of refactorings}\label{correctness}
972 For automated refactorings to be truly useful, they must show a high degree of
973 behavior preservation. This last sentence might seem obvious, but there are
974 examples of refactorings in existing tools that break programs. In an ideal
975 world, every automated refactoring would be ``complete'', in the sense that it
976 would never break a program. In an ideal world, every program would also be free
977 from bugs. In modern IDEs the implemented automated refactorings are working for
978 \emph{most} cases, that is enough for making them useful.
980 I will now present an example of a \emph{corner case} where a program breaks
981 when a refactoring is applied. The example shows an \ExtractMethod refactoring
982 followed by a \MoveMethod refactoring that breaks a program in both the
983 \name{Eclipse} and \name{IntelliJ} IDEs\footnote{The \name{NetBeans} IDE handles this
984 particular situation without altering the program's behavior, mainly because
985 its \refa{Move Method} refactoring implementation is a bit flawed in other ways
986 \see{toolSupport}.}. The target and the destination for the composed
987 refactoring is shown in \myref{lst:correctnessExtractAndMove}. Note that the
988 method \method{m(C c)} of class \type{X} assigns to the field \var{x} of the
989 argument \var{c} that has type \type{C}.
993 \begin{minted}[linenos]{java}
994 // Refactoring target
996 public X x = new X();
1008 \begin{minted}[]{java}
1009 // Method destination
1011 public void m(C c) {
1013 // If m is called from
1014 // c, then c.x no longer
1021 \caption{The target and the destination for the composition of the Extract
1022 Method and \refa{Move Method} refactorings.}
1023 \label{lst:correctnessExtractAndMove}
1027 The refactoring sequence works by extracting line 6 through 8 from the original
1028 class \type{C} into a method \method{f} with the statements from those lines as
1029 its method body (but with the comment left out, since it will no longer hold any
1030 meaning). The method is then moved to the class \type{X}. The result is shown
1031 in \myref{lst:correctnessExtractAndMoveResult}.
1033 Before the refactoring, the methods \method{m} and \method{n} of class \type{X}
1034 are called on different object instances (see line 6 and 8 of the original class
1035 \type{C} in \cref{lst:correctnessExtractAndMove}). After the refactoring, they
1036 are called on the same object, and the statement on line
1037 3 of class \type{X} (in \cref{lst:correctnessExtractAndMoveResult}) no longer
1038 has the desired effect in our example. The method \method{f} of class \type{C}
1039 is now calling the method \method{f} of class \type{X} (see line 5 of class
1040 \type{C} in \cref{lst:correctnessExtractAndMoveResult}), and the program now
1041 behaves different than before.
1044 \begin{multicols}{2}
1045 \begin{minted}[linenos]{java}
1047 public X x = new X();
1057 \begin{minted}[linenos]{java}
1059 public void m(C c) {
1065 public void f(C c) {
1072 \caption{The result of the composed refactoring.}
1073 \label{lst:correctnessExtractAndMoveResult}
1076 The bug introduced in the previous example is of such a nature\footnote{Caused
1077 by aliasing. See \url{https://en.wikipedia.org/wiki/Aliasing_(computing)}}
1078 that it is very difficult to spot if the refactored code is not covered by
1079 tests. It does not generate compilation errors, and will thus only result in
1080 a runtime error or corrupted data, which might be hard to detect.
1082 \section{Refactoring and the importance of testing}\label{testing}
1084 If you want to refactor, the essential precondition is having solid
1085 tests.\citing{refactoring}
1088 When refactoring, there are roughly three classes of errors that can be made.
1089 The first class of errors are the ones that make the code unable to compile.
1090 These \emph{compile-time} errors are of the nicer kind. They flash up at the
1091 moment they are made (at least when using an IDE), and are usually easy to fix.
1092 The second class are the \emph{runtime} errors. Although they take a bit longer
1093 to surface, they usually manifest after some time in an illegal argument
1094 exception, null pointer exception or similar during the program execution.
1095 These kind of errors are a bit harder to handle, but at least they will show,
1096 eventually. Then there are the \emph{behavior-changing} errors. These errors are
1097 of the worst kind. They do not show up during compilation and they do not turn
1098 on a blinking red light during runtime either. The program can seem to work
1099 perfectly fine with them in play, but the business logic can be damaged in ways
1100 that will only show up over time.
1102 For discovering runtime errors and behavior changes when refactoring, it is
1103 essential to have good test coverage. Testing in this context means writing
1104 automated tests. Manual testing may have its uses, but when refactoring, it is
1105 automated unit testing that dominate. For discovering behavior changes it is
1106 especially important to have tests that cover potential problems, since these
1107 kind of errors does not reveal themselves.
1109 Unit testing is not a way to \emph{prove} that a program is correct, but it is a
1110 way to make you confident that it \emph{probably} works as desired. In the
1111 context of test driven development (commonly known as TDD), the tests are even a
1112 way to define how the program is \emph{supposed} to work. It is then, by
1113 definition, working if the tests are passing.
1115 If the test coverage for a code base is perfect, then it should, theoretically,
1116 be risk-free to perform refactorings on it. This is why automated tests and
1117 refactoring are such a great match.
1119 \subsection{Testing the code from correctness section}
1120 The worst thing that can happen when refactoring is to introduce changes to the
1121 behavior of a program, as in the example on \myref{correctness}. This example
1122 may be trivial, but the essence is clear. The only problem with the example is
1123 that it is not clear how to create automated tests for it, without changing it
1126 Unit tests, as they are known from the different \glosspl{xUnit} around, are
1127 only suitable to test the \emph{result} of isolated operations. They can not
1128 easily (if at all) observe the \emph{history} of a program.
1130 This problem is still open.
1134 Assuming a sequential (non-concurrent) program:
1136 \begin{minted}{java}
1137 tracematch (C c, X x) {
1139 call(* X.m(C)) && args(c) && cflow(within(C));
1141 call(* X.n()) && target(x) && cflow(within(C));
1143 set(C.x) && target(c) && !cflow(m);
1147 { assert x == c.x; }
1151 %\begin{minted}{java}
1152 %tracematch (X x1, X x2) {
1154 % call(* X.m(C)) && target(x1);
1156 % call(* X.n()) && target(x2);
1158 % set(C.x) && !cflow(m) && !cflow(n);
1162 % { assert x1 != x2; }
1168 \chapter{The Project}
1170 \todoin{Moved from introduction to here. Rewrite and make problem statement from
1172 The aim of this master project will be to investigate the relationship between a
1173 composite refactoring composed of the \ExtractMethod and \MoveMethod
1174 refactorings, and its impact on one or more software metrics.
1176 The composition of the \ExtractMethod and \MoveMethod refactorings springs
1177 naturally out of the need to move procedures closer to the data they manipulate.
1178 This composed refactoring is not well described in the literature, but it is
1179 implemented in at least one tool called
1180 \name{CodeRush}\footnote{\url{https://help.devexpress.com/\#CodeRush/CustomDocument3519}},
1181 that is an extension for \name{MS Visual
1182 Studio}\footnote{\url{http://www.visualstudio.com/}}. In CodeRush it is called
1183 \refa{Extract Method to
1184 Type}\footnote{\url{https://help.devexpress.com/\#CodeRush/CustomDocument6710}},
1185 but I choose to call it \ExtractAndMoveMethod, since I feel it better
1186 communicates which primitive refactorings it is composed of.
1188 For the metrics, I will at least measure the \metr{Coupling between object
1189 classes} (CBO) metric that is described by Chidamber and Kemerer in their
1190 article \tit{A Metrics Suite for Object Oriented
1191 Design}\citing{metricsSuite1994}.
1193 The project will then consist in implementing the \ExtractAndMoveMethod
1194 refactoring, as well as executing it over a larger code base. Then the effect of
1195 the change must be measured by calculating the chosen software metrics both
1196 before and after the execution. To be able to execute the refactoring
1197 automatically I have to make it analyze code to determine the best selections to
1198 extract into new methods.
1199 \section{The problem statement}
1202 \section{The refactorings}
1204 \subsection{The Extract Method refactoring}
1205 The \refa{Extract Method} refactoring is used to extract a fragment of code
1206 from its context and into a new method. A call to the new method is inlined
1207 where the fragment was before. It is used to break code into logical units,
1208 with names that explain their purpose
1210 \missingfigure{Explaining the Extract Method refactoring}
1212 \subsection{The Move Method refactoring}
1213 The \refa{Move Method} refactoring is used to move a method from one class to
1214 another. This is useful if the method is using more features of another class
1215 than of the class which it is currently defined.
1217 \missingfigure{Explaining the Move Method refactoring}
1219 \subsection{The Extract and Move Method refactoring}
1221 \missingfigure{Explaining the Extract and Move Method refactoring}
1224 \section{Choosing the target language}
1225 Choosing which programming language the code that shall be manipulated shall be
1226 written in, is not a very difficult task. We choose to limit the possible
1227 languages to the object-oriented programming languages, since most of the
1228 terminology and literature regarding refactoring comes from the world of
1229 object-oriented programming. In addition, the language must have existing tool
1230 support for refactoring.
1232 The \name{Java} programming language\footnote{\url{https://www.java.com/}} is
1233 the dominating language when it comes to example code in the literature of
1234 refactoring, and is thus a natural choice. Java is perhaps, currently the most
1235 influential programming language in the world, with its \name{Java Virtual
1236 Machine} that runs on all of the most popular architectures and also supports
1237 dozens of other programming languages\footnote{They compile to java bytecode.},
1238 with \name{Scala}, \name{Clojure} and \name{Groovy} as the most prominent ones.
1239 Java is currently the language that every other programming language is compared
1240 against. It is also the primary programming language for the author of this
1243 \section{Choosing the tools}
1244 When choosing a tool for manipulating Java, there are certain criteria that
1245 have to be met. First of all, the tool should have some existing refactoring
1246 support that this thesis can build upon. Secondly it should provide some kind of
1247 framework for parsing and analyzing Java source code. Third, it should itself be
1248 open source. This is both because of the need to be able to browse the code for
1249 the existing refactorings that is contained in the tool, and also because open
1250 source projects hold value in them selves. Another important aspect to consider
1251 is that open source projects of a certain size, usually has large communities of
1252 people connected to them, that are committed to answering questions regarding the
1253 use and misuse of the products, that to a large degree is made by the community
1256 There is a certain class of tools that meet these criteria, namely the class of
1257 \emph{IDEs}\footnote{\emph{Integrated Development Environment}}. These are
1258 programs that is meant to support the whole production cycle of a computer
1259 program, and the most popular IDEs that support Java, generally have quite good
1260 refactoring support.
1262 The main contenders for this thesis is the \name{Eclipse IDE}, with the
1263 \name{Java development tools} (JDT), the \name{IntelliJ IDEA Community Edition}
1264 and the \name{NetBeans IDE} \see{toolSupport}. \name{Eclipse} and
1265 \name{NetBeans} are both free, open source and community driven, while the
1266 \name{IntelliJ IDEA} has an open sourced community edition that is free of
1267 charge, but also offer an \name{Ultimate Edition} with an extended set of
1268 features, at additional cost. All three IDEs supports adding plugins to extend
1269 their functionality and tools that can be used to parse and analyze Java source
1270 code. But one of the IDEs stand out as a favorite, and that is the \name{Eclipse
1271 IDE}. This is the most popular\citing{javaReport2011} among them and seems to be
1272 de facto standard IDE for Java development regardless of platform.
1274 \section{Source code organization}
1275 All the parts of this master project is under version control with
1276 \name{Git}\footnote{\url{http://git-scm.com/}}.
1278 The software written is organized as some \name{Eclipse} plugins. Writing a plugin is
1279 the natural way to utilize the API of \name{Eclipse}. This also makes it possible to
1280 provide a user interface to manually run operations on selections in program
1281 source code or whole projects/packages.
1283 When writing a plugin in \name{Eclipse}, one has access to resources such as the
1284 current workspace, the open editor and the current selection.
1286 The thesis work is contained in the following Eclipse projects:
1289 \item[no.uio.ifi.refaktor] \hfill \\ This is the main Eclipse plugin
1290 project, and contains all of the business logic for the plugin.
1292 \item[no.uio.ifi.refaktor.tests] \hfill \\
1293 This project contains the tests for the main plugin.
1295 \item[no.uio.ifi.refaktor.examples] \hfill \\
1296 Contains example code used in testing. It also contains code for managing
1297 this example code, such as creating an Eclipse project from it before a test
1300 \item[no.uio.ifi.refaktor.benchmark] \hfill \\
1301 This project contains code for running search based versions of the
1302 composite refactoring over selected Eclipse projects.
1304 \item[no.uio.ifi.refaktor.releng] \hfill \\
1305 Contains the rmap, queries and target definitions needed by by Buckminster
1306 on the Jenkins continuous integration server.
1310 \subsection{The no.uio.ifi.refaktor project}
1312 \subsubsection{no.uio.ifi.refaktor.analyze}
1313 This package, and its subpackages, contains code that is used for analyzing Java
1314 source code. The most important subpackages are presented below.
1317 \item[no.uio.ifi.refaktor.analyze.analyzers] \hfill \\
1318 This package contains source code analyzers. These are usually responsible
1319 for analyzing text selections or running specialized analyzers for different
1320 kinds of entities. Their structure are often hierarchical. This means that
1321 you have an analyzer for text selections, that in turn is utilized by an
1322 analyzer that analyzes all the selections of a method. Then there are
1323 analyzers for analyzing all the methods of a type, all the types of a
1324 compilation unit, all the compilation units of a package, and, at last, all
1325 of the packages in a project.
1327 \item[no.uio.ifi.refaktor.analyze.checkers] \hfill \\
1328 A package containing checkers. The checkers are classes used to validate
1329 that a selection can be further analyzed and chosen as a candidate for a
1330 refactoring. Invalidating properties can be such as usage of inner classes
1331 or the need for multiple return values.
1333 \item[no.uio.ifi.refaktor.analyze.collectors] \hfill \\
1334 This package contains the property collectors. Collectors are used to gather
1335 properties from a text selection. This is mostly properties regarding
1336 referenced names and their occurrences. It is these properties that makes up
1337 the basis for finding the best candidates for a refactoring.
1340 \subsubsection{no.uio.ifi.refaktor.change}
1341 This package, and its subpackages, contains functionality for manipulate source
1345 \item[no.uio.ifi.refaktor.change.changers] \hfill \\
1346 This package contains source code changers. They are used to glue together
1347 the analysis of source code and the actual execution of the changes.
1349 \item[no.uio.ifi.refaktor.change.executors] \hfill \\
1350 The executors that are responsible for making concrete changes are found in
1351 this package. They are mostly used to create and execute one or more Eclipse
1354 \item[no.uio.ifi.refaktor.change.processors] \hfill \\
1355 Contains a refactoring processor for the \MoveMethod refactoring. The code
1356 is stolen and modified to fix a bug. The related bug is described in
1357 \myref{eclipse_bug_429416}.
1361 \subsubsection{no.uio.ifi.refaktor.handlers}
1362 This package contains handlers for the commands defined in the plugin manifest.
1364 \subsubsection{no.uio.ifi.refaktor.prefix}
1365 This package contains the \type{Prefix} type that is the data representation of
1366 the prefixes found by the \type{PrefixesCollector}. It also contains the prefix
1367 set for storing and working with prefixes.
1369 \subsubsection{no.uio.ifi.refaktor.statistics}
1370 The package contains statistics functionality. Its heart is the statistics
1371 aspect that is responsible for gathering statistics during the execution of the
1372 \ExtractAndMoveMethod refactoring.
1375 \item[no.uio.ifi.refaktor.statistics.reports] \hfill \\
1376 This package contains a simple framework for generating reports from the
1377 statistics data generated by the aspect. Currently, the only available
1378 report type is a simple text report.
1383 \subsubsection{no.uio.ifi.refaktor.textselection}
1384 This package contains the two custom text selections that are used extensively
1385 throughout the project. One of them is just a subclass of the other, to support
1386 the use of the memento pattern to optimize the memory usage during benchmarking.
1388 \subsubsection{no.uio.ifi.refaktor.debugging}
1389 The package contains a debug utility class. I addition to this, the package
1390 \code{no.uio.ifi.refaktor.utils.aspects} contains a couple of aspects used for
1393 \subsubsection{no.uio.ifi.refaktor.utils}
1394 Utility package that contains all the functionality that has to do with parsing
1395 of source code. It also has utility classes for looking up handles to methods
1396 and types et cetera.
1399 \item[no.uio.ifi.refaktor.utils.caching] \hfill \\
1400 This package contains the caching manager for compilation units, along with
1401 classes for different caching strategies.
1403 \item[no.uio.ifi.refaktor.utils.nullobjects] \hfill \\
1404 Contains classes for creating different null objects. Most of the classes is
1405 used to represent null objects of different handle types. These null objects
1406 are returned from various utility classes instead of returning a \var{null}
1407 value when other values are not available.
1413 \section{Continuous integration}
1414 The continuous integration server
1415 \name{Jenkins}\footnote{\url{http://jenkins-ci.org/}} has been set up for the
1416 project\footnote{A work mostly done by the supervisor.}. It is used as a way to
1417 run tests and perform code coverage analysis.
1419 To be able to build the \name{Eclipse} plugins and run tests for them with Jenkins, the
1420 component assembly project
1421 \name{Buckminster}\footnote{\url{http://www.eclipse.org/buckminster/}} is used,
1422 through its plugin for Jenkins. Buckminster provides for a way to specify the
1423 resources needed for building a project and where and how to find them.
1424 Buckminster also handles the setup of a target environment to run the tests in.
1425 All this is needed because the code to build depends on an \name{Eclipse}
1426 installation with various plugins.
1428 \subsection{Problems with AspectJ}
1429 The Buckminster build worked fine until introducing AspectJ into the project.
1430 When building projects using AspectJ, there are some additional steps that needs
1431 to be performed. First of all, the aspects themselves must be compiled. Then the
1432 aspects needs to be woven with the classes they affect. This demands a process
1433 that does multiple passes over the source code.
1435 When using AspectJ with \name{Eclipse}, the specialized compilation and the
1436 weaving can be handled by the \name{AspectJ Development
1437 Tools}\footnote{\url{https://www.eclipse.org/ajdt/}}. This works all fine, but
1438 it complicates things when trying to build a project depending on \name{Eclipse}
1439 plugins outside of \name{Eclipse}. There is supposed to be a way to specify a
1440 compiler adapter for javac, together with the file extensions for the file types
1441 it shall operate. The AspectJ compiler adapter is called
1442 \typewithref{org.aspectj.tools.ant.taskdefs}{Ajc11CompilerAdapter}, and it works
1443 with files that has the extensions \code{*.java} and \code{*.aj}. I tried to
1444 setup this in the build properties file for the project containing the aspects,
1445 but to no avail. The project containing the aspects does not seem to be built at
1446 all, and the projects that depends on it complains that they cannot find certain
1449 I then managed to write an \name{Ant}\footnote{\url{https://ant.apache.org/}}
1450 build file that utilizes the AspectJ compiler adapter, for the
1451 \code{no.uio.ifi.refaktor} plugin. The problem was then that it could no longer
1452 take advantage of the environment set up by Buckminster. The solution to this
1453 particular problem was of a ``hacky'' nature. It involves exporting the plugin
1454 dependencies for the project to an Ant build file, and copy the exported path
1455 into the existing build script. But then the Ant script needs to know where the
1456 local \name{Eclipse} installation is located. This is no problem when building
1457 on a local machine, but to utilize the setup done by Buckminster is a problem
1458 still unsolved. To get the classpath for the build setup correctly, and here
1459 comes the most ``hacky'' part of the solution, the Ant script has a target for
1460 copying the classpath elements into a directory relative to the project
1461 directory and checking it into Git. When no \code{ECLIPSE\_HOME} property is set
1462 while running Ant, the script uses the copied plugins instead of the ones
1463 provided by the \name{Eclipse} installation when building the project. This
1464 obviously creates some problems with maintaining the list of dependencies in the
1465 Ant file, as well as remembering to copy the plugins every time the list of
1466 dependencies change.
1468 The Ant script described above is run by Jenkins before the Buckminster setup
1469 and build. When setup like this, the Buckminster build succeeds for the projects
1470 not using AspectJ, and the tests are run as normal. This is all good, but it
1471 feels a little scary, since the reason for Buckminster not working with AspectJ
1474 The problems with building with AspectJ on the Jenkins server lasted for a
1475 while, before they were solved. This is reflected in the ``Test Result Trend''
1476 and ``Code Coverage Trend'' reported by Jenkins.
1480 \chapter{Refactorings in Eclipse JDT: Design, Shortcomings and Wishful
1481 Thinking}\label{ch:jdt_refactorings}
1483 This chapter will deal with some of the design behind refactoring support in
1484 \name{Eclipse}, and the JDT in specific. After which it will follow a section about
1485 shortcomings of the refactoring API in terms of composition of refactorings. The
1486 chapter will be concluded with a section telling some of the ways the
1487 implementation of refactorings in the JDT could have worked to facilitate
1488 composition of refactorings.
1491 The refactoring world of \name{Eclipse} can in general be separated into two parts: The
1492 language independent part and the part written for a specific programming
1493 language -- the language that is the target of the supported refactorings.
1494 \todo{What about the language specific part?}
1496 \subsection{The Language Toolkit}
1497 The Language Toolkit\footnote{The content of this section is a mixture of
1498 written material from
1499 \url{https://www.eclipse.org/articles/Article-LTK/ltk.html} and
1500 \url{http://www.eclipse.org/articles/article.php?file=Article-Unleashing-the-Power-of-Refactoring/index.html},
1501 the LTK source code and my own memory.}, or LTK for short, is the framework that
1502 is used to implement refactorings in \name{Eclipse}. It is language independent and
1503 provides the abstractions of a refactoring and the change it generates, in the
1504 form of the classes \typewithref{org.eclipse.ltk.core.refactoring}{Refactoring}
1505 and \typewithref{org.eclipse.ltk.core.refactoring}{Change}.
1507 There are also parts of the LTK that is concerned with user interaction, but
1508 they will not be discussed here, since they are of little value to us and our
1509 use of the framework. We are primarily interested in the parts that can be
1512 \subsubsection{The Refactoring Class}
1513 The abstract class \type{Refactoring} is the core of the LTK framework. Every
1514 refactoring that is going to be supported by the LTK have to end up creating an
1515 instance of one of its subclasses. The main responsibilities of subclasses of
1516 \type{Refactoring} is to implement template methods for condition checking
1517 (\methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{checkInitialConditions}
1519 \methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{checkFinalConditions}),
1521 \methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{createChange}
1522 method that creates and returns an instance of the \type{Change} class.
1524 If the refactoring shall support that others participate in it when it is
1525 executed, the refactoring has to be a processor-based
1526 refactoring\typeref{org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring}.
1527 It then delegates to its given
1528 \typewithref{org.eclipse.ltk.core.refactoring.participants}{RefactoringProcessor}
1529 for condition checking and change creation. Participating in a refactoring can
1530 be useful in cases where the changes done to programming source code affects
1531 other related resources in the workspace. This can be names or paths in
1532 configuration files, or maybe one would like to perform additional logging of
1533 changes done in the workspace.
1535 \subsubsection{The Change Class}
1536 This class is the base class for objects that is responsible for performing the
1537 actual workspace transformations in a refactoring. The main responsibilities for
1538 its subclasses is to implement the
1539 \methodwithref{org.eclipse.ltk.core.refactoring.Change}{perform} and
1540 \methodwithref{org.eclipse.ltk.core.refactoring.Change}{isValid} methods. The
1541 \method{isValid} method verifies that the change object is valid and thus can be
1542 executed by calling its \method{perform} method. The \method{perform} method
1543 performs the desired change and returns an undo change that can be executed to
1544 reverse the effect of the transformation done by its originating change object.
1546 \subsubsection{Executing a Refactoring}\label{executing_refactoring}
1547 The life cycle of a refactoring generally follows two steps after creation:
1548 condition checking and change creation. By letting the refactoring object be
1550 \typewithref{org.eclipse.ltk.core.refactoring}{CheckConditionsOperation} that
1551 in turn is handled by a
1552 \typewithref{org.eclipse.ltk.core.refactoring}{CreateChangeOperation}, it is
1553 assured that the change creation process is managed in a proper manner.
1555 The actual execution of a change object has to follow a detailed life cycle.
1556 This life cycle is honored if the \type{CreateChangeOperation} is handled by a
1557 \typewithref{org.eclipse.ltk.core.refactoring}{PerformChangeOperation}. If also
1558 an undo manager\typeref{org.eclipse.ltk.core.refactoring.IUndoManager} is set
1559 for the \type{PerformChangeOperation}, the undo change is added into the undo
1562 \section{Shortcomings}
1563 This section is introduced naturally with a conclusion: The JDT refactoring
1564 implementation does not facilitate composition of refactorings.
1565 \todo{refine}This section will try to explain why, and also identify other
1566 shortcomings of both the usability and the readability of the JDT refactoring
1569 I will begin at the end and work my way toward the composition part of this
1572 \subsection{Absence of Generics in Eclipse Source Code}
1573 This section is not only concerning the JDT refactoring API, but also large
1574 quantities of the \name{Eclipse} source code. The code shows a striking absence of the
1575 Java language feature of generics. It is hard to read a class' interface when
1576 methods return objects or takes parameters of raw types such as \type{List} or
1577 \type{Map}. This sometimes results in having to read a lot of source code to
1578 understand what is going on, instead of relying on the available interfaces. In
1579 addition, it results in a lot of ugly code, making the use of typecasting more
1580 of a rule than an exception.
1582 \subsection{Composite Refactorings Will Not Appear as Atomic Actions}
1584 \subsubsection{Missing Flexibility from JDT Refactorings}
1585 The JDT refactorings are not made with composition of refactorings in mind. When
1586 a JDT refactoring is executed, it assumes that all conditions for it to be
1587 applied successfully can be found by reading source files that have been
1588 persisted to disk. They can only operate on the actual source material, and not
1589 (in-memory) copies thereof. This constitutes a major disadvantage when trying to
1590 compose refactorings, since if an exception occurs in the middle of a sequence
1591 of refactorings, it can leave the project in a state where the composite
1592 refactoring was only partially executed. It makes it hard to discard the changes
1593 done without monitoring and consulting the undo manager, an approach that is not
1596 \subsubsection{Broken Undo History}
1597 When designing a composed refactoring that is to be performed as a sequence of
1598 refactorings, you would like it to appear as a single change to the workspace.
1599 This implies that you would also like to be able to undo all the changes done by
1600 the refactoring in a single step. This is not the way it appears when a sequence
1601 of JDT refactorings is executed. It leaves the undo history filled up with
1602 individual undo actions corresponding to every single JDT refactoring in the
1603 sequence. This problem is not trivial to handle in \name{Eclipse}
1604 \see{hacking_undo_history}.
1606 \section{Wishful Thinking}
1609 \chapter{Composite Refactorings in Eclipse}
1611 \section{A Simple Ad Hoc Model}
1612 As pointed out in \myref{ch:jdt_refactorings}, the \name{Eclipse} JDT refactoring model
1613 is not very well suited for making composite refactorings. Therefore a simple
1614 model using changer objects (of type \type{RefaktorChanger}) is used as an
1615 abstraction layer on top of the existing \name{Eclipse} refactorings, instead of
1616 extending the \typewithref{org.eclipse.ltk.core.refactoring}{Refactoring} class.
1618 The use of an additional abstraction layer is a deliberate choice. It is due to
1619 the problem of creating a composite
1620 \typewithref{org.eclipse.ltk.core.refactoring}{Change} that can handle text
1621 changes that interfere with each other. Thus, a \type{RefaktorChanger} may, or
1622 may not, take advantage of one or more existing refactorings, but it is always
1623 intended to make a change to the workspace.
1625 \subsection{A typical \type{RefaktorChanger}}
1626 The typical refaktor changer class has two responsibilities, checking
1627 preconditions and executing the requested changes. This is not too different
1628 from the responsibilities of an LTK refactoring, with the distinction that a
1629 refaktor changer also executes the change, while an LTK refactoring is only
1630 responsible for creating the object that can later be used to do the job.
1632 Checking of preconditions is typically done by an
1633 \typewithref{no.uio.ifi.refaktor.analyze.analyzers}{Analyzer}. If the
1634 preconditions validate, the upcoming changes are executed by an
1635 \typewithref{no.uio.ifi.refaktor.change.executors}{Executor}.
1637 \section{The Extract and Move Method Refactoring}
1638 %The Extract and Move Method Refactoring is implemented mainly using these
1641 % \item \type{ExtractAndMoveMethodChanger}
1642 % \item \type{ExtractAndMoveMethodPrefixesExtractor}
1643 % \item \type{Prefix}
1644 % \item \type{PrefixSet}
1647 \subsection{The Building Blocks}
1648 This is a composite refactoring, and hence is built up using several primitive
1649 refactorings. These basic building blocks are, as its name implies, the
1650 \ExtractMethod refactoring\citing{refactoring} and the \MoveMethod
1651 refactoring\citing{refactoring}. In \name{Eclipse}, the implementations of these
1652 refactorings are found in the classes
1653 \typewithref{org.eclipse.jdt.internal.corext.refactoring.code}{ExtractMethodRefactoring}
1655 \typewithref{org.eclipse.jdt.internal.corext.refactoring.structure}{MoveInstanceMethodProcessor},
1656 where the last class is designed to be used together with the processor-based
1657 \typewithref{org.eclipse.ltk.core.refactoring.participants}{MoveRefactoring}.
1659 \subsubsection{The ExtractMethodRefactoring Class}
1660 This class is quite simple in its use. The only parameters it requires for
1661 construction is a compilation
1662 unit\typeref{org.eclipse.jdt.core.ICompilationUnit}, the offset into the source
1663 code where the extraction shall start, and the length of the source to be
1664 extracted. Then you have to set the method name for the new method together with
1665 its visibility and some not so interesting parameters.
1667 \subsubsection{The MoveInstanceMethodProcessor Class}
1668 For the \refa{Move Method}, the processor requires a little more advanced input than
1669 the class for the \refa{Extract Method}. For construction it requires a method
1670 handle\typeref{org.eclipse.jdt.core.IMethod} for the method that is to be moved.
1671 Then the target for the move have to be supplied as the variable binding from a
1672 chosen variable declaration. In addition to this, one have to set some
1673 parameters regarding setters/getters, as well as delegation.
1675 To make a working refactoring from the processor, one have to create a
1676 \type{MoveRefactoring} with it.
1678 \subsection{The ExtractAndMoveMethodChanger}
1680 The \typewithref{no.uio.ifi.refaktor.changers}{ExtractAndMoveMethodChanger}
1681 class is a subclass of the class
1682 \typewithref{no.uio.ifi.refaktor.changers}{RefaktorChanger}. It is responsible
1683 for analyzing and finding the best target for, and also executing, a composition
1684 of the \refa{Extract Method} and \refa{Move Method} refactorings. This particular changer is
1685 the one of my changers that is closest to being a true LTK refactoring. It can
1686 be reworked to be one if the problems with overlapping changes are resolved. The
1687 changer requires a text selection and the name of the new method, or else a
1688 method name will be generated. The selection has to be of the type
1689 \typewithref{no.uio.ifi.refaktor.utils}{CompilationUnitTextSelection}. This
1690 class is a custom extension to
1691 \typewithref{org.eclipse.jface.text}{TextSelection}, that in addition to the
1692 basic offset, length and similar methods, also carry an instance of the
1693 underlying compilation unit handle for the selection.
1696 \type{ExtractAndMoveMethodAnalyzer}}\label{extractAndMoveMethodAnalyzer}
1697 The analysis and precondition checking is done by the
1698 \typewithref{no.uio.ifi.refaktor.analyze.analyzers}{ExtractAnd\-MoveMethodAnalyzer}.
1699 First is check whether the selection is a valid selection or not, with respect
1700 to statement boundaries and that it actually contains any selections. Then it
1701 checks the legality of both extracting the selection and also moving it to
1702 another class. This checking of is performed by a range of checkers
1703 \see{checkers}. If the selection is approved as legal, it is analyzed to find
1704 the presumably best target to move the extracted method to.
1706 For finding the best suitable target the analyzer is using a
1707 \typewithref{no.uio.ifi.refaktor.analyze.collectors}{PrefixesCollector} that
1708 collects all the possible candidate targets for the refactoring. All the
1709 non-candidates is found by an
1710 \typewithref{no.uio.ifi.refaktor.analyze.collectors}{UnfixesCollector} that
1711 collects all the targets that will give some kind of error if used. (For
1712 details about the property collectors, see \myref{propertyCollectors}.) All
1713 prefixes (and unfixes) are represented by a
1714 \typewithref{no.uio.ifi.refaktor.extractors}{Prefix}, and they are collected
1715 into sets of prefixes. The safe prefixes is found by subtracting from the set of
1716 candidate prefixes the prefixes that is enclosing any of the unfixes. A prefix
1717 is enclosing an unfix if the unfix is in the set of its sub-prefixes. As an
1718 example, \texttt{``a.b''} is enclosing \texttt{``a''}, as is \texttt{``a''}. The
1719 safe prefixes is unified in a \type{PrefixSet}. If a prefix has only one
1720 occurrence, and is a simple expression, it is considered unsuitable as a move
1721 target. This occurs in statements such as \texttt{``a.foo()''}. For such
1722 statements it bares no meaning to extract and move them. It only generates an
1723 extra method and the calling of it.
1725 The most suitable target for the refactoring is found by finding the prefix with
1726 the most occurrences. If two prefixes have the same occurrence count, but they
1727 differ in length, the longest of them is chosen.
1729 \todoin{Clean up sections/subsections.}
1732 \type{ExtractAndMoveMethodExecutor}}\label{extractAndMoveMethodExecutor}
1733 If the analysis finds a possible target for the composite refactoring, it is
1735 \typewithref{no.uio.ifi.refaktor.change.executors}{ExtractAndMoveMethodExecutor}.
1736 It is composed of the two executors known as
1737 \typewithref{no.uio.ifi.refaktor.change.executors}{ExtractMethodRefactoringExecutor}
1739 \typewithref{no.uio.ifi.refaktor.change.executors}{MoveMethodRefactoringExecutor}.
1740 The \type{ExtractAndMoveMethodExecutor} is responsible for gluing the two
1741 together by feeding the \type{MoveMethod\-RefactoringExecutor} with the
1742 resources needed after executing the extract method refactoring.
1743 %\see{postExtractExecution}.
1745 \subsubsection{The \type{ExtractMethodRefactoringExecutor}}
1746 This executor is responsible for creating and executing an instance of the
1747 \type{ExtractMethodRefactoring} class. It is also responsible for collecting
1748 some post execution resources that can be used to find the method handle for the
1749 extracted method, as well as information about its parameters, including the
1750 variable they originated from.
1752 \subsubsection{The \type{MoveMethodRefactoringExecutor}}
1753 This executor is responsible for creating and executing an instance of the
1754 \type{MoveRefactoring}. The move refactoring is a processor-based refactoring,
1755 and for the \refa{Move Method} refactoring it is the \type{MoveInstanceMethodProcessor}
1758 The handle for the method to be moved is found on the basis of the information
1759 gathered after the execution of the \refa{Extract Method} refactoring. The only
1760 information the \type{ExtractMethodRefactoring} is sharing after its execution,
1761 regarding find the method handle, is the textual representation of the new
1762 method signature. Therefore it must be parsed, the strings for types of the
1763 parameters must be found and translated to a form that can be used to look up
1764 the method handle from its type handle. They have to be on the unresolved
1765 form.\todo{Elaborate?} The name for the type is found from the original
1766 selection, since an extracted method must end up in the same type as the
1769 When analyzing a selection prior to performing the \refa{Extract Method} refactoring, a
1770 target is chosen. It has to be a variable binding, so it is either a field or a
1771 local variable/parameter. If the target is a field, it can be used with the
1772 \type{MoveInstanceMethodProcessor} as it is, since the extracted method still is
1773 in its scope. But if the target is local to the originating method, the target
1774 that is to be used for the processor must be among its parameters. Thus the
1775 target must be found among the extracted method's parameters. This is done by
1776 finding the parameter information object that corresponds to the parameter that
1777 was declared on basis of the original target's variable when the method was
1778 extracted. (The extracted method must take one such parameter for each local
1779 variable that is declared outside the selection that is extracted.) To match the
1780 original target with the correct parameter information object, the key for the
1781 information object is compared to the key from the original target's binding.
1782 The source code must then be parsed to find the method declaration for the
1783 extracted method. The new target must be found by searching through the
1784 parameters of the declaration and choose the one that has the same type as the
1785 old binding from the parameter information object, as well as the same name that
1786 is provided by the parameter information object.
1790 SearchBasedExtractAndMoveMethodChanger}\label{searchBasedExtractAndMoveMethodChanger}
1792 \typewithref{no.uio.ifi.refaktor.change.changers}{SearchBasedExtractAndMoveMethodChanger}
1793 is a changer whose purpose is to automatically analyze a method, and execute the
1794 \ExtractAndMoveMethod refactoring on it if it is a suitable candidate for the
1797 First, the \typewithref{no.uio.ifi.refaktor.analyze.analyzers}{SearchBasedExtractAndMoveMethodAnalyzer} is used
1798 to analyze the method. If the method is found to be a candidate, the result from
1799 the analysis is fed to the \type{ExtractAndMoveMethodExecutor}, whose job is to
1800 execute the refactoring \see{extractAndMoveMethodExecutor}.
1802 \subsubsection{The SearchBasedExtractAndMoveMethodAnalyzer}
1803 This analyzer is responsible for analyzing all the possible text selections of a
1804 method and then choose the best result out of the analysis results that is, by
1805 the analyzer, considered to be the potential candidates for the Extract and Move
1808 Before the analyzer is able to work with the text selections of a method, it
1809 needs to generate them. To do this, it parses the method to obtain a
1810 \type{MethodDeclaration} for it \see{astEclipse}. Then there is a statement
1811 lists creator that creates statements lists of the different groups of
1812 statements in the body of the method declaration. A text selections generator
1813 generates text selections of all the statement lists for the analyzer to work
1816 \paragraph{The statement lists creator}
1817 is responsible for generating lists of statements for all the possible levels of
1818 statements in the method. The statement lists creator is implemented as an AST
1819 visitor \see{astVisitor}. It generates lists of statements by visiting all the
1820 blocks in the method declaration and stores their statements in a collection of
1821 statement lists. In addition, it visits all of the other statements that can
1822 have a statement as a child, such as the different control structures and the
1825 The switch statement is the only kind of statement that is not straight forward
1826 to obtain the child statements from. It stores all of its children in a flat
1827 list. Its switch case statements are included in this list. This means that
1828 there are potential statement lists between all of these case statements. The
1829 list of statements from a switch statement is therefore traversed, and the
1830 statements between the case statements are grouped as separate lists.
1832 There is an example of how the statement lists creator would generate lists for
1833 a simple method in \myref{lst:statementListsExample}.
1836 \def\charwidth{5.7pt}
1837 \def\indent{4*\charwidth}
1838 \def\lineheight{\baselineskip}
1839 \def\mintedtop{\lineheight}
1841 \begin{tikzpicture}[overlay, yscale=-1]
1842 \tikzstyle{overlaybox}=[fill=lightgray,opacity=0.2]
1843 \draw[overlaybox] (0,\mintedtop+\lineheight) rectangle
1844 +(22*\charwidth,10*\lineheight);
1845 \draw[overlaybox] (\indent,\mintedtop+2*\lineheight) rectangle
1846 +(13*\charwidth,\lineheight);
1847 \draw[overlaybox] (2*\indent,\mintedtop+6*\lineheight) rectangle
1848 +(13*\charwidth,2*\lineheight);
1849 \draw[overlaybox] (2*\indent,\mintedtop+9*\lineheight) rectangle
1850 +(13*\charwidth,\lineheight);
1852 \begin{minted}{java}
1866 \caption{Example of how the statement lists creator would group a simple method
1867 into lists of statements. Each highlighted rectangle represents a list.}
1868 \label{lst:statementListsExample}
1871 \paragraph{The text selections generator} generates text selections for each
1872 list of statements from the statement lists creator. Conceptually, the generator
1873 generates a text selection for every possible ordered \todo{make clearer}
1874 combination of statements in a list. For a list of statements, the boundary
1875 statements span out a text selection. This means that there are many different
1876 lists that could span out the same selection.
1878 In practice, the text selections are calculated by only one traversal of the
1879 statement list. There is a set of generated text selections. For each statement,
1880 there is created a temporary set of selections, in addition to a text selection
1881 based on the offset and length of the statement. This text selection is added to
1882 the temporary set. Then the new selection is added with every selection from the
1883 set of generated text selections. These new selections are added to the
1884 temporary set. Then the temporary set of selections is added to the set of
1885 generated text selections. The result of adding two text selections is a new
1886 text selection spanned out by the two addends.
1889 \def\charwidth{5.7pt}
1890 \def\indent{4*\charwidth}
1891 \def\lineheight{\baselineskip}
1892 \def\mintedtop{\lineheight}
1894 \begin{tikzpicture}[overlay, yscale=-1]
1895 \tikzstyle{overlaybox}=[fill=lightgray,opacity=0.2]
1897 \draw[overlaybox] (2*\charwidth,\mintedtop) rectangle
1898 +(18*\charwidth,\lineheight);
1900 \draw[overlaybox] (2*\charwidth,\mintedtop+\lineheight) rectangle
1901 +(18*\charwidth,\lineheight);
1903 \draw[overlaybox] (2*\charwidth,\mintedtop+3*\lineheight) rectangle
1904 +(18*\charwidth,\lineheight);
1906 \draw[overlaybox] (\indent-3*\charwidth,\mintedtop) rectangle
1907 +(20*\charwidth,2*\lineheight);
1909 \draw[overlaybox] (3*\charwidth,\mintedtop+\lineheight) rectangle
1910 +(16*\charwidth,3*\lineheight);
1912 \draw[overlaybox] (\indent,\mintedtop) rectangle
1913 +(14*\charwidth,4*\lineheight);
1915 \begin{minted}{java}
1921 \caption{Example of how the text selections generator would generate text
1922 selections based on a lists of statements. Each highlighted rectangle
1923 represents a text selection.}
1924 \label{lst:textSelectionsExample}
1926 \todoin{fix \myref{lst:textSelectionsExample}?}
1928 \paragraph{Finding the candidate} for the refactoring is done by analyzing all
1929 the generated text selection with the \type{ExtractAndMoveMethodAnalyzer}
1930 \see{extractAndMoveMethodAnalyzer}. If the analyzer generates a useful result,
1931 an \type{ExtractAndMoveMethodCandidate} is created from it, that is kept in a
1932 list of potential candidates. If no candidates are found, the
1933 \type{NoTargetFoundException} is thrown.
1935 Since only one of the candidates can be chosen, the analyzer must sort out which
1936 candidate to choose. The sorting is done by the static \method{sort} method of
1937 \type{Collections}. The comparison in this sorting is done by an
1938 \type{ExtractAndMoveMethodCandidateComparator}.
1939 \todoin{Write about the
1940 ExtractAndMoveMethodCandidateComparator/FavorNoUnfixesCandidateComparator}
1942 \paragraph{The complexity} of how many text selections that needs to be analyzed
1943 for a total of $n$ statements is bounded by $O(n^2)$.
1946 The number of text selections that need to be analyzed for each list of
1947 statements of length $n$, is exactly
1950 \sum_{i=1}^{n} i = \frac{n(n+1)}{2}
1951 \label{eq:complexityStatementList}
1953 \label{thm:numberOfTextSelection}
1957 For $n=1$ this is trivial: $\frac{1(1+1)}{2} = \frac{2}{2} = 1$. One statement
1958 equals one selection.
1960 For $n=2$, you get one text selection for the first statement. For the second,
1961 you get one selection for the statement itself, and one selection for the two
1962 of them combined. This equals three selections. $\frac{2(2+1)}{2} =
1965 For $n=3$, you get 3 selections for the two first statements, as in the case
1966 where $n=2$. In addition you get one selection for the third statement itself,
1967 and two more statements for the combinations of it with the two previous
1968 statements. This equals six selections. $\frac{3(3+1)}{2} = \frac{12}{2} = 6$.
1970 Assume that for $n=k$ there exists $\frac{k(k+1)}{2}$ text selections. Then we
1971 want to add selections for another statement, following the previous $k$
1972 statements. So, for $n=k+1$, we get one additional selection for the statement
1973 itself. Then we get one selection for each pair of the new selection and the
1974 previous $k$ statements. So the total number of selections will be the number
1975 of already generated selections, plus $k$ for every pair, plus one for the
1976 statement itself: $\frac{k(k+1)}{2} + k +
1977 1 = \frac{k(k+1)+2k+2}{2} = \frac{k(k+1)+2(k+1)}{2} = \frac{(k+1)(k+2)}{2} =
1978 \frac{(k+1)((k+1)+1)}{2} = \sum_{i=1}^{k+1} i$
1982 The number of text selections for a body of statements is maximized if all the
1983 statements are at the same level.
1984 \label{thm:textSelectionsMaximized}
1988 Assume we have a body of, in total, $k$ statements. Let
1989 $l,\cdots,m,(k-l-\cdots-m)$ be the lengths of the lists of statements in the
1990 body, with $l+\cdots+m<k \Rightarrow l,\cdots,m<k$.
1992 Then, the number of text selections that are generated for the $k$ statements
1998 \frac{(k-l-\cdots-m)((k-l-\cdots-m)+ 1)}{2} + \frac{l(l+1)}{2} + \cdots +
1999 \frac{m(m+1)}{2} = \\
2000 \frac{k^2 - 2kl - \cdots - 2km + l^2 + \cdots + m^2 + k - l - \cdots - m}{2}
2001 + \frac{l^2+l}{2} + \cdots + \frac{m^2+m}{2} = \\
2002 \frac{k^2 + k + 2l^2 - 2kl + \cdots + 2m^2 - 2km}{2}
2006 It then remains to show that this inequality holds:
2009 \frac{k^2 + k + 2l^2 - 2kl + \cdots + 2m^2 - 2km}{2} < \frac{k(k+1)}{2} =
2013 By multiplication by $2$ on both sides, and by removing the equal parts, we get
2016 2l^2 - 2kl + \cdots + 2m^2 - 2km < 0
2019 Since $l,\cdots,m<k$, we have that $\forall i \in \{l,\cdots,m\} : 2ki > 2i^2$,
2020 so all the pairs of parts on the form $2i^2-2ki$ are negative. In sum, the
2025 Therefore, the complexity for the number of selections that needs to be analyzed
2026 for a body of $n$ statements is $O\bigl(\frac{n(n+1)}{2}\bigr) = O(n^2)$.
2030 \subsection{Finding the IMethod}\label{postExtractExecution}
2031 \todoin{Rename section. Write??}
2035 \subsection{The Prefix Class}
2036 This class exists mainly for holding data about a prefix, such as the expression
2037 that the prefix represents and the occurrence count of the prefix within a
2038 selection. In addition to this, it has some functionality such as calculating
2039 its sub-prefixes and intersecting it with another prefix. The definition of the
2040 intersection between two prefixes is a prefix representing the longest common
2041 expression between the two.
2043 \subsection{The PrefixSet Class}
2044 A prefix set holds elements of type \type{Prefix}. It is implemented with the
2045 help of a \typewithref{java.util}{HashMap} and contains some typical set
2046 operations, but it does not implement the \typewithref{java.util}{Set}
2047 interface, since the prefix set does not need all of the functionality a
2048 \type{Set} requires to be implemented. In addition It needs some other
2049 functionality not found in the \type{Set} interface. So due to the relatively
2050 limited use of prefix sets, and that it almost always needs to be referenced as
2051 such, and not a \type{Set<Prefix>}, it remains as an ad hoc solution to a
2054 There are two ways adding prefixes to a \type{PrefixSet}. The first is through
2055 its \method{add} method. This works like one would expect from a set. It adds
2056 the prefix to the set if it does not already contain the prefix. The other way
2057 is to \emph{register} the prefix with the set. When registering a prefix, if the
2058 set does not contain the prefix, it is just added. If the set contains the
2059 prefix, its count gets incremented. This is how the occurrence count is handled.
2061 The prefix set also computes the set of prefixes that is not enclosing any
2062 prefixes of another set. This is kind of a set difference operation only for
2065 \subsection{Hacking the Refactoring Undo
2066 History}\label{hacking_undo_history}
2067 \todoin{Where to put this section?}
2069 As an attempt to make multiple subsequent changes to the workspace appear as a
2070 single action (i.e. make the undo changes appear as such), I tried to alter
2071 the undo changes\typeref{org.eclipse.ltk.core.refactoring.Change} in the history
2072 of the refactorings.
2074 My first impulse was to remove the, in this case, last two undo changes from the
2075 undo manager\typeref{org.eclipse.ltk.core.refactoring.IUndoManager} for the
2076 \name{Eclipse} refactorings, and then add them to a composite
2077 change\typeref{org.eclipse.ltk.core.refactoring.CompositeChange} that could be
2078 added back to the manager. The interface of the undo manager does not offer a
2079 way to remove/pop the last added undo change, so a possible solution could be to
2080 decorate\citing{designPatterns} the undo manager, to intercept and collect the
2081 undo changes before delegating to the \method{addUndo}
2082 method\methodref{org.eclipse.ltk.core.refactoring.IUndoManager}{addUndo} of the
2083 manager. Instead of giving it the intended undo change, a null change could be
2084 given to prevent it from making any changes if run. Then one could let the
2085 collected undo changes form a composite change to be added to the manager.
2087 There is a technical challenge with this approach, and it relates to the undo
2088 manager, and the concrete implementation
2089 UndoManager2\typeref{org.eclipse.ltk.internal.core.refactoring.UndoManager2}.
2090 This implementation is designed in a way that it is not possible to just add an
2091 undo change, you have to do it in the context of an active
2092 operation\typeref{org.eclipse.core.commands.operations.TriggeredOperations}.
2093 One could imagine that it might be possible to trick the undo manager into
2094 believing that you are doing a real change, by executing a refactoring that is
2095 returning a kind of null change that is returning our composite change of undo
2096 refactorings when it is performed.
2098 Apart from the technical problems with this solution, there is a functional
2099 problem: If it all had worked out as planned, this would leave the undo history
2100 in a dirty state, with multiple empty undo operations corresponding to each of
2101 the sequentially executed refactoring operations, followed by a composite undo
2102 change corresponding to an empty change of the workspace for rounding of our
2103 composite refactoring. The solution to this particular problem could be to
2104 intercept the registration of the intermediate changes in the undo manager, and
2105 only register the last empty change.
2107 Unfortunately, not everything works as desired with this solution. The grouping
2108 of the undo changes into the composite change does not make the undo operation
2109 appear as an atomic operation. The undo operation is still split up into
2110 separate undo actions, corresponding to the change done by its originating
2111 refactoring. And in addition, the undo actions has to be performed separate in
2112 all the editors involved. This makes it no solution at all, but a step toward
2115 There might be a solution to this problem, but it remains to be found. The
2116 design of the refactoring undo management is partly to be blamed for this, as it
2117 it is to complex to be easily manipulated.
2122 \chapter{Analyzing Source Code in Eclipse}
2124 \section{The Java model}\label{javaModel}
2125 The Java model of \name{Eclipse} is its internal representation of a Java project. It
2126 is light-weight, and has only limited possibilities for manipulating source
2127 code. It is typically used as a basis for the Package Explorer in \name{Eclipse}.
2129 The elements of the Java model is only handles to the underlying elements. This
2130 means that the underlying element of a handle does not need to actually exist.
2131 Hence the user of a handle must always check that it exist by calling the
2132 \method{exists} method of the handle.
2134 The handles with descriptions is listed in \myref{tab:javaModel}.
2139 \newcolumntype{L}[1]{>{\hsize=#1\hsize\raggedright\arraybackslash}X}%
2140 % sum must equal number of columns (3)
2141 \begin{tabularx}{\textwidth}{| L{0.7} | L{1.1} | L{1.2} |}
2143 \textbf{Project Element} & \textbf{Java Model element} &
2144 \textbf{Description} \\
2146 Java project & \type{IJavaProject} & The Java project which contains all other objects. \\
2148 Source folder /\linebreak[2] binary folder /\linebreak[3] external library &
2149 \type{IPackageFragmentRoot} & Hold source or binary files, can be a folder
2150 or a library (zip / jar file). \\
2152 Each package & \type{IPackageFragment} & Each package is below the
2153 \type{IPackageFragmentRoot}, sub-packages are not leaves of the package,
2154 they are listed directed under \type{IPackageFragmentRoot}. \\
2156 Java Source file & \type{ICompilationUnit} & The Source file is always below
2157 the package node. \\
2159 Types /\linebreak[2] Fields /\linebreak[3] Methods & \type{IType} /
2161 \type{IField} /\linebreak[3] \type{IMethod} & Types, fields and methods. \\
2164 \caption{The elements of the Java Model. {\footnotesize Taken from
2165 \url{http://www.vogella.com/tutorials/EclipseJDT/article.html}}}
2166 \label{tab:javaModel}
2169 The hierarchy of the Java Model is shown in \myref{fig:javaModel}.
2173 \begin{tikzpicture}[%
2174 grow via three points={one child at (0,-0.7) and
2175 two children at (0,-0.7) and (0,-1.4)},
2176 edge from parent path={(\tikzparentnode.south west)+(0.5,0) |-
2177 (\tikzchildnode.west)}]
2178 \tikzstyle{every node}=[draw=black,thick,anchor=west]
2179 \tikzstyle{selected}=[draw=red,fill=red!30]
2180 \tikzstyle{optional}=[dashed,fill=gray!50]
2181 \node {\type{IJavaProject}}
2182 child { node {\type{IPackageFragmentRoot}}
2183 child { node {\type{IPackageFragment}}
2184 child { node {\type{ICompilationUnit}}
2185 child { node {\type{IType}}
2186 child { node {\type{\{ IType \}*}}
2187 child { node {\type{\ldots}}}
2190 child { node {\type{\{ IField \}*}}}
2191 child { node {\type{IMethod}}
2192 child { node {\type{\{ IType \}*}}
2193 child { node {\type{\ldots}}}
2198 child { node {\type{\{ IMethod \}*}}}
2207 child { node {\type{\{ IType \}*}}}
2218 child { node {\type{\{ ICompilationUnit \}*}}}
2231 child { node {\type{\{ IPackageFragment \}*}}}
2246 child { node {\type{\{ IPackageFragmentRoot \}*}}}
2249 \caption{The Java model of \name{Eclipse}. ``\type{\{ SomeElement \}*}'' means
2250 \type{SomeElement} zero or more times. For recursive structures,
2251 ``\type{\ldots}'' is used.}
2252 \label{fig:javaModel}
2255 \section{The Abstract Syntax Tree}
2256 \name{Eclipse} is following the common paradigm of using an abstract syntax tree for
2257 source code analysis and manipulation.
2259 When parsing program source code into something that can be used as a foundation
2260 for analysis, the start of the process follows the same steps as in a compiler.
2261 This is all natural, because the way a compiler analyzes code is no different
2262 from how source manipulation programs would do it, except for some properties of
2263 code that is analyzed in the parser, and that they may be differing in what
2264 kinds of properties they analyze. Thus the process of translation source code
2265 into a structure that is suitable for analyzing, can be seen as a kind of
2266 interrupted compilation process \see{fig:interruptedCompilationProcess}.
2271 base/.style={anchor=north, align=center, rectangle, minimum height=1.4cm},
2272 basewithshadow/.style={base, drop shadow, fill=white},
2273 outlined/.style={basewithshadow, draw, rounded corners, minimum
2275 primary/.style={outlined, font=\bfseries},
2276 dashedbox/.style={outlined, dashed},
2277 arrowpath/.style={black, align=center, font=\small},
2278 processarrow/.style={arrowpath, ->, >=angle 90, shorten >=1pt},
2280 \begin{tikzpicture}[node distance=1.3cm and 3cm, scale=1, every
2281 node/.style={transform shape}]
2282 \node[base](AuxNode1){\small source code};
2283 \node[primary, right=of AuxNode1, xshift=-2.5cm](Scanner){Scanner};
2284 \node[primary, right=of Scanner, xshift=0.5cm](Parser){Parser};
2285 \node[dashedbox, below=of Parser](SemanticAnalyzer){Semantic\\Analyzer};
2286 \node[dashedbox, left=of SemanticAnalyzer](SourceCodeOptimizer){Source
2288 \node[dashedbox, below=of SourceCodeOptimizer
2289 ](CodeGenerator){Code\\Generator};
2290 \node[dashedbox, right=of CodeGenerator](TargetCodeOptimizer){Target
2292 \node[base, right=of TargetCodeOptimizer](AuxNode2){};
2294 \draw[processarrow](AuxNode1) -- (Scanner);
2296 \path[arrowpath] (Scanner) -- node [sloped](tokens){tokens}(Parser);
2297 \draw[processarrow](Scanner) -- (tokens) -- (Parser);
2299 \path[arrowpath] (Parser) -- node (syntax){syntax
2300 tree}(SemanticAnalyzer);
2301 \draw[processarrow](Parser) -- (syntax) -- (SemanticAnalyzer);
2303 \path[arrowpath] (SemanticAnalyzer) -- node
2304 [sloped](annotated){annotated\\tree}(SourceCodeOptimizer);
2305 \draw[processarrow, dashed](SemanticAnalyzer) -- (annotated) --
2306 (SourceCodeOptimizer);
2308 \path[arrowpath] (SourceCodeOptimizer) -- node
2309 (intermediate){intermediate code}(CodeGenerator);
2310 \draw[processarrow, dashed](SourceCodeOptimizer) -- (intermediate) --
2313 \path[arrowpath] (CodeGenerator) -- node [sloped](target1){target
2314 code}(TargetCodeOptimizer);
2315 \draw[processarrow, dashed](CodeGenerator) -- (target1) --
2316 (TargetCodeOptimizer);
2318 \path[arrowpath](TargetCodeOptimizer) -- node [sloped](target2){target
2320 \draw[processarrow, dashed](TargetCodeOptimizer) -- (target2) (AuxNode2);
2322 \caption{Interrupted compilation process. {\footnotesize (Full compilation
2323 process borrowed from \emph{Compiler construction: principles and practice}
2324 by Kenneth C. Louden\citing{louden1997}.)}}
2325 \label{fig:interruptedCompilationProcess}
2328 The process starts with a \emph{scanner}, or lexer. The job of the scanner is to
2329 read the source code and divide it into tokens for the parser. Therefore, it is
2330 also sometimes called a tokenizer. A token is a logical unit, defined in the
2331 language specification, consisting of one or more consecutive characters. In
2332 the Java language the tokens can for instance be the \var{this} keyword, a curly
2333 bracket \var{\{} or a \var{nameToken}. It is recognized by the scanner on the
2334 basis of something equivalent of a regular expression. This part of the process
2335 is often implemented with the use of a finite automata. In fact, it is common to
2336 specify the tokens in regular expressions, that in turn is translated into a
2337 finite automata lexer. This process can be automated.
2339 The program component used to translate a stream of tokens into something
2340 meaningful, is called a parser. A parser is fed tokens from the scanner and
2341 performs an analysis of the structure of a program. It verifies that the syntax
2342 is correct according to the grammar rules of a language, that is usually
2343 specified in a context-free grammar, and often in a variant of the
2345 Form}\footnote{\url{https://en.wikipedia.org/wiki/Backus-Naur\_Form}}. The
2346 result coming from the parser is in the form of an \emph{Abstract Syntax Tree},
2347 AST for short. It is called \emph{abstract}, because the structure does not
2348 contain all of the tokens produced by the scanner. It only contain logical
2349 constructs, and because it forms a tree, all kinds of parentheses and brackets
2350 are implicit in the structure. It is this AST that is used when performing the
2351 semantic analysis of the code.
2353 As an example we can think of the expression \code{(5 + 7) * 2}. The root of
2354 this tree would in \name{Eclipse} be an \type{InfixExpression} with the operator
2355 \var{TIMES}, and a left operand that is also an \type{InfixExpression} with the
2356 operator \var{PLUS}. The left operand \type{InfixExpression}, has in turn a left
2357 operand of type \type{NumberLiteral} with the value \var{``5''} and a right
2358 operand \type{NumberLiteral} with the value \var{``7''}. The root will have a
2359 right operand of type \type{NumberLiteral} and value \var{``2''}. The AST for
2360 this expression is illustrated in \myref{fig:astInfixExpression}.
2362 Contrary to the Java Model, an abstract syntax tree is a heavy-weight
2363 representation of source code. It contains information about properties like
2364 type bindings for variables and variable bindings for names.
2369 \begin{tikzpicture}[scale=0.8]
2370 \tikzset{level distance=40pt}
2371 \tikzset{sibling distance=5pt}
2372 \tikzstyle{thescale}=[scale=0.8]
2373 \tikzset{every tree node/.style={align=center}}
2374 \tikzset{edge from parent/.append style={thick}}
2375 \tikzstyle{inode}=[rectangle,rounded corners,draw,fill=lightgray,drop
2376 shadow,align=center]
2377 \tikzset{every internal node/.style={inode}}
2378 \tikzset{every leaf node/.style={draw=none,fill=none}}
2380 \Tree [.\type{InfixExpression} [.\type{InfixExpression}
2381 [.\type{NumberLiteral} \var{``5''} ] [.\type{Operator} \var{PLUS} ]
2382 [.\type{NumberLiteral} \var{``7''} ] ]
2383 [.\type{Operator} \var{TIMES} ]
2384 [.\type{NumberLiteral} \var{``2''} ]
2387 \caption{The abstract syntax tree for the expression \code{(5 + 7) * 2}.}
2388 \label{fig:astInfixExpression}
2391 \subsection{The AST in Eclipse}\label{astEclipse}
2392 In \name{Eclipse}, every node in the AST is a child of the abstract superclass
2393 \typewithref{org.eclipse.jdt.core.dom}{ASTNode}. Every \type{ASTNode}, among a
2394 lot of other things, provides information about its position and length in the
2395 source code, as well as a reference to its parent and to the root of the tree.
2397 The root of the AST is always of type \type{CompilationUnit}. It is not the same
2398 as an instance of an \type{ICompilationUnit}, which is the compilation unit
2399 handle of the Java model. The children of a \type{CompilationUnit} is an
2400 optional \type{PackageDeclaration}, zero or more nodes of type
2401 \type{ImportDecaration} and all its top-level type declarations that has node
2402 types \type{AbstractTypeDeclaration}.
2404 An \type{AbstractType\-Declaration} can be one of the types
2405 \type{AnnotationType\-Declaration}, \type{Enum\-Declaration} or
2406 \type{Type\-Declaration}. The children of an \type{AbstractType\-Declaration}
2407 must be a subtype of a \type{BodyDeclaration}. These subtypes are:
2408 \type{AnnotationTypeMember\-Declaration}, \type{EnumConstant\-Declaration},
2409 \type{Field\-Declaration}, \type{Initializer} and \type{Method\-Declaration}.
2411 Of the body declarations, the \type{Method\-Declaration} is the most interesting
2412 one. Its children include lists of modifiers, type parameters, parameters and
2413 exceptions. It has a return type node and a body node. The body, if present, is
2414 of type \type{Block}. A \type{Block} is itself a \type{Statement}, and its
2415 children is a list of \type{Statement} nodes.
2417 There are too many types of the abstract type \type{Statement} to list up, but
2418 there exists a subtype of \type{Statement} for every statement type of Java, as
2419 one would expect. This also applies to the abstract type \type{Expression}.
2420 However, the expression \type{Name} is a little special, since it is both used
2421 as an operand in compound expressions, as well as for names in type declarations
2424 There is an overview of some of the structure of an \name{Eclipse} AST in
2425 \myref{fig:astEclipse}.
2429 \begin{tikzpicture}[scale=0.8]
2430 \tikzset{level distance=50pt}
2431 \tikzset{sibling distance=5pt}
2432 \tikzstyle{thescale}=[scale=0.8]
2433 \tikzset{every tree node/.style={align=center}}
2434 \tikzset{edge from parent/.append style={thick}}
2435 \tikzstyle{inode}=[rectangle,rounded corners,draw,fill=lightgray,drop
2436 shadow,align=center]
2437 \tikzset{every internal node/.style={inode}}
2438 \tikzset{every leaf node/.style={draw=none,fill=none}}
2440 \Tree [.\type{CompilationUnit} [.\type{[ PackageDeclaration ]} [.\type{Name} ]
2441 [.\type{\{ Annotation \}*} ] ]
2442 [.\type{\{ ImportDeclaration \}*} [.\type{Name} ] ]
2443 [.\type{\{ AbstractTypeDeclaration \}+} [.\node(site){\type{\{
2444 BodyDeclaration \}*}}; ] [.\type{SimpleName} ] ]
2446 \begin{scope}[shift={(0.5,-6)}]
2447 \node[inode,thescale](root){\type{MethodDeclaration}};
2448 \node[inode,thescale](modifiers) at (4.5,-5){\type{\{ IExtendedModifier \}*}
2449 \\ {\footnotesize (Of type \type{Modifier} or \type{Annotation})}};
2450 \node[inode,thescale](typeParameters) at (-6,-3.5){\type{\{ TypeParameter
2452 \node[inode,thescale](parameters) at (-5,-5){\type{\{
2453 SingleVariableDeclaration \}*} \\ {\footnotesize (Parameters)}};
2454 \node[inode,thescale](exceptions) at (5,-3){\type{\{ Name \}*} \\
2455 {\footnotesize (Exceptions)}};
2456 \node[inode,thescale](return) at (-6.5,-2){\type{Type} \\ {\footnotesize
2458 \begin{scope}[shift={(0,-5)}]
2459 \Tree [.\node(body){\type{[ Block ]} \\ {\footnotesize (Body)}};
2460 [.\type{\{ Statement \}*} [.\type{\{ Expression \}*} ]
2461 [.\type{\{ Statement \}*} [.\type{\ldots} ]]
2466 \draw[->,>=triangle 90,shorten >=1pt](root.east)..controls +(east:2) and
2467 +(south:1)..(site.south);
2469 \draw (root.south) -- (modifiers);
2470 \draw (root.south) -- (typeParameters);
2471 \draw (root.south) -- ($ (parameters.north) + (2,0) $);
2472 \draw (root.south) -- (exceptions);
2473 \draw (root.south) -- (return);
2474 \draw (root.south) -- (body);
2477 \caption{The format of the abstract syntax tree in \name{Eclipse}.}
2478 \label{fig:astEclipse}
2480 \todoin{Add more to the AST format tree? \myref{fig:astEclipse}}
2482 \section{The ASTVisitor}\label{astVisitor}
2483 So far, the only thing that has been addressed is how the data that is going to
2484 be the basis for our analysis is structured. Another aspect of it is how we are
2485 going to traverse the AST to gather the information we need, so we can conclude
2486 about the properties we are analysing. It is of course possible to start at the
2487 top of the tree, and manually search through its nodes for the ones we are
2488 looking for, but that is a bit inconvenient. To be able to efficiently utilize
2489 such an approach, we would need to make our own framework for traversing the
2490 tree and visiting only the types of nodes we are after. Luckily, this
2491 functionality is already provided in \name{Eclipse}, by its
2492 \typewithref{org.eclipse.jdt.core.dom}{ASTVisitor}.
2494 The \name{Eclipse} AST, together with its \type{ASTVisitor}, follows the
2495 \pattern{Visitor} pattern\citing{designPatterns}. The intent of this design
2496 pattern is to facilitate extending the functionality of classes without touching
2497 the classes themselves.
2499 Let us say that there is a class hierarchy of elements. These elements all have
2500 a method \method{accept(Visitor visitor)}. In its simplest form, the
2501 \method{accept} method just calls the \method{visit} method of the visitor with
2502 itself as an argument, like this: \code{visitor.visit(this)}. For the visitors
2503 to be able to extend the functionality of all the classes in the elements
2504 hierarchy, each \type{Visitor} must have one visit method for each concrete
2505 class in the hierarchy. Say the hierarchy consists of the concrete classes
2506 \type{ConcreteElementA} and \type{ConcreteElementB}. Then each visitor must have
2507 the (possibly empty) methods \method{visit(ConcreteElementA element)} and
2508 \method{visit(ConcreteElementB element)}. This scenario is depicted in
2509 \myref{fig:visitorPattern}.
2513 \tikzstyle{abstract}=[rectangle, draw=black, fill=white, drop shadow, text
2514 centered, anchor=north, text=black, text width=6cm, every one node
2515 part/.style={align=center, font=\bfseries\itshape}]
2516 \tikzstyle{concrete}=[rectangle, draw=black, fill=white, drop shadow, text
2517 centered, anchor=north, text=black, text width=6cm]
2518 \tikzstyle{inheritarrow}=[->, >=open triangle 90, thick]
2519 \tikzstyle{commentarrow}=[->, >=angle 90, dashed]
2520 \tikzstyle{line}=[-, thick]
2521 \tikzset{every one node part/.style={align=center, font=\bfseries}}
2522 \tikzset{every second node part/.style={align=center, font=\ttfamily}}
2524 \begin{tikzpicture}[node distance=1cm, scale=0.8, every node/.style={transform
2526 \node (Element) [abstract, rectangle split, rectangle split parts=2]
2528 \nodepart{one}{Element}
2529 \nodepart{second}{+accept(visitor: Visitor)}
2531 \node (AuxNode01) [text width=0, minimum height=2cm, below=of Element] {};
2532 \node (ConcreteElementA) [concrete, rectangle split, rectangle split
2533 parts=2, left=of AuxNode01]
2535 \nodepart{one}{ConcreteElementA}
2536 \nodepart{second}{+accept(visitor: Visitor)}
2538 \node (ConcreteElementB) [concrete, rectangle split, rectangle split
2539 parts=2, right=of AuxNode01]
2541 \nodepart{one}{ConcreteElementB}
2542 \nodepart{second}{+accept(visitor: Visitor)}
2545 \node[comment, below=of ConcreteElementA] (CommentA) {visitor.visit(this)};
2547 \node[comment, below=of ConcreteElementB] (CommentB) {visitor.visit(this)};
2549 \node (AuxNodeX) [text width=0, minimum height=1cm, below=of AuxNode01] {};
2551 \node (Visitor) [abstract, rectangle split, rectangle split parts=2,
2554 \nodepart{one}{Visitor}
2555 \nodepart{second}{+visit(ConcreteElementA)\\+visit(ConcreteElementB)}
2557 \node (AuxNode02) [text width=0, minimum height=2cm, below=of Visitor] {};
2558 \node (ConcreteVisitor1) [concrete, rectangle split, rectangle split
2559 parts=2, left=of AuxNode02]
2561 \nodepart{one}{ConcreteVisitor1}
2562 \nodepart{second}{+visit(ConcreteElementA)\\+visit(ConcreteElementB)}
2564 \node (ConcreteVisitor2) [concrete, rectangle split, rectangle split
2565 parts=2, right=of AuxNode02]
2567 \nodepart{one}{ConcreteVisitor2}
2568 \nodepart{second}{+visit(ConcreteElementA)\\+visit(ConcreteElementB)}
2572 \draw[inheritarrow] (ConcreteElementA.north) -- ++(0,0.7) -|
2574 \draw[line] (ConcreteElementA.north) -- ++(0,0.7) -|
2575 (ConcreteElementB.north);
2577 \draw[inheritarrow] (ConcreteVisitor1.north) -- ++(0,0.7) -|
2579 \draw[line] (ConcreteVisitor1.north) -- ++(0,0.7) -|
2580 (ConcreteVisitor2.north);
2582 \draw[commentarrow] (CommentA.north) -- (ConcreteElementA.south);
2583 \draw[commentarrow] (CommentB.north) -- (ConcreteElementB.south);
2587 \caption{The Visitor Pattern.}
2588 \label{fig:visitorPattern}
2591 The use of the visitor pattern can be appropriate when the hierarchy of elements
2592 is mostly stable, but the family of operations over its elements is constantly
2593 growing. This is clearly the case for the \name{Eclipse} AST, since the hierarchy of
2594 type \type{ASTNode} is very stable, but the functionality of its elements is
2595 extended every time someone needs to operate on the AST. Another aspect of the
2596 \name{Eclipse} implementation is that it is a public API, and the visitor pattern is an
2597 easy way to provide access to the nodes in the tree.
2599 The version of the visitor pattern implemented for the AST nodes in \name{Eclipse} also
2600 provides an elegant way to traverse the tree. It does so by following the
2601 convention that every node in the tree first let the visitor visit itself,
2602 before it also makes all its children accept the visitor. The children are only
2603 visited if the visit method of their parent returns \var{true}. This pattern
2604 then makes for a prefix traversal of the AST. If postfix traversal is desired,
2605 the visitors also has \method{endVisit} methods for each node type, that is
2606 called after the \method{visit} method for a node. In addition to these visit
2607 methods, there are also the methods \method{preVisit(ASTNode)},
2608 \method{postVisit(ASTNode)} and \method{preVisit2(ASTNode)}. The
2609 \method{preVisit} method is called before the type-specific \method{visit}
2610 method. The \method{postVisit} method is called after the type-specific
2611 \method{endVisit}. The type specific \method{visit} is only called if
2612 \method{preVisit2} returns \var{true}. Overriding the \method{preVisit2} is also
2613 altering the behavior of \method{preVisit}, since the default implementation is
2614 responsible for calling it.
2616 An example of a trivial \type{ASTVisitor} is shown in
2617 \myref{lst:astVisitorExample}.
2620 \begin{minted}{java}
2621 public class CollectNamesVisitor extends ASTVisitor {
2622 Collection<Name> names = new LinkedList<Name>();
2625 public boolean visit(QualifiedName node) {
2631 public boolean visit(SimpleName node) {
2637 \caption{An \type{ASTVisitor} that visits all the names in a subtree and adds
2638 them to a collection, except those names that are children of any
2639 \type{QualifiedName}.}
2640 \label{lst:astVisitorExample}
2643 \section{Property collectors}\label{propertyCollectors}
2644 The prefixes and unfixes are found by property
2645 collectors\typeref{no.uio.ifi.refaktor.extractors.collectors.PropertyCollector}.
2646 A property collector is of the \type{ASTVisitor} type, and thus visits nodes of
2647 type \type{ASTNode} of the abstract syntax tree \see{astVisitor}.
2649 \subsection{The PrefixesCollector}
2650 The \typewithref{no.uio.ifi.refaktor.extractors.collectors}{PrefixesCollector}
2651 finds prefixes that makes up the basis for calculating move targets for the
2652 \refa{Extract and Move Method} refactoring. It visits expression
2653 statements\typeref{org.eclipse.jdt.core.dom.ExpressionStatement} and creates
2654 prefixes from its expressions in the case of method invocations. The prefixes
2655 found is registered with a prefix set, together with all its sub-prefixes.
2657 \subsection{The UnfixesCollector}\label{unfixes}
2658 The \typewithref{no.uio.ifi.refaktor.extractors.collectors}{UnfixesCollector}
2659 finds unfixes within a selection. That is prefixes that cannot be used as a
2660 basis for finding a move target in a refactoring.
2662 An unfix can be a name that is assigned to within a selection. The reason that
2663 this cannot be allowed, is that the result would be an assignment to the
2664 \type{this} keyword, which is not valid in Java \see{eclipse_bug_420726}.
2666 Prefixes that originates from variable declarations within the same selection
2667 are also considered unfixes. This is because when a method is moved, it needs to
2668 be called through a variable. If this variable is also within the method that is
2669 to be moved, this obviously cannot be done.
2671 Also considered as unfixes are variable references that are of types that is not
2672 suitable for moving a methods to. This can be either because it is not
2673 physically possible to move the method to the desired class or that it will
2674 cause compilation errors by doing so.
2676 If the type binding for a name is not resolved it is considered and unfix. The
2677 same applies to types that is only found in compiled code, so they have no
2678 underlying source that is accessible to us. (E.g. the \type{java.lang.String}
2681 Interfaces types are not suitable as targets. This is simply because interfaces
2682 in Java cannot contain methods with bodies. (This thesis does not deal with
2683 features of Java versions later than Java 7. Java 8 has interfaces with default
2684 implementations of methods.) Neither are local types allowed. This accounts for
2685 both local and anonymous classes. Anonymous classes are effectively the same as
2686 interface types with respect to unfixes. Local classes could in theory be used
2687 as targets, but this is not possible due to limitations of the implementation of
2688 the \refa{Extract and Move Method} refactoring. The problem is that the refactoring is
2689 done in two steps, so the intermediate state between the two refactorings would
2690 not be legal Java code. In the case of local classes, the problem is that, in
2691 the intermediate step, a selection referencing a local class would need to take
2692 the local class as a parameter if it were to be extracted to a new method. This
2693 new method would need to live in the scope of the declaring class of the
2694 originating method. The local class would then not be in the scope of the
2695 extracted method, thus bringing the source code into an illegal state. One could
2696 imagine that the method was extracted and moved in one operation, without an
2697 intermediate state. Then it would make sense to include variables with types of
2698 local classes in the set of legal targets, since the local classes would then be
2699 in the scopes of the method calls. If this makes any difference for software
2700 metrics that measure coupling would be a different discussion.
2703 \begin{multicols}{2}
2704 \begin{minted}[]{java}
2706 void declaresLocalClass() {
2721 \begin{minted}[]{java}
2722 // After Extract Method
2723 void declaresLocalClass() {
2734 // Intermediate step
2735 void fooBar(LocalClass inst) {
2741 \caption{When \refa{Extract and Move Method} tries to use a variable with a local type
2742 as the move target, an intermediate step is taken that is not allowed. Here:
2743 \type{LocalClass} is not in the scope of \method{fooBar} in its intermediate
2745 \label{lst:extractMethod_LocalClass}
2748 The last class of names that are considered unfixes is names used in null tests.
2749 These are tests that reads like this: if \texttt{<name>} equals \var{null} then
2750 do something. If allowing variables used in those kinds of expressions as
2751 targets for moving methods, we would end up with code containing boolean
2752 expressions like \texttt{this == null}, which would not be meaningful, since
2753 \var{this} would never be \var{null}.
2756 \subsection{The ContainsReturnStatementCollector}
2758 \typewithref{no.uio.ifi.refaktor.analyze.collectors}{ContainsReturnStatementCollector}
2759 is a very simple property collector. It only visits the return statements within
2760 a selection, and can report whether it encountered a return statement or not.
2762 \subsection{The LastStatementCollector}
2763 The \typewithref{no.uio.ifi.refaktor.analyze.collectors}{LastStatementCollector}
2764 collects the last statement of a selection. It does so by only visiting the top
2765 level statements of the selection, and compares the textual end offset of each
2766 encountered statement with the end offset of the previous statement found.
2768 \section{Checkers}\label{checkers}
2769 \todoin{Check out ExtractMethodAnalyzer from ExtractMethodRefactoring}
2770 The checkers are a range of classes that checks that text selections complies
2771 with certain criteria. All checkers operates under the assumption that the code
2772 they check is free from compilation errors. If a
2773 \typewithref{no.uio.ifi.refaktor.analyze.analyzers}{Checker} fails, it throws a
2774 \type{CheckerException}. The checkers are managed by the
2775 \type{LegalStatementsChecker}, which does not, in fact, implement the
2776 \type{Checker} interface. It does, however, run all the checkers registered with
2777 it, and reports that all statements are considered legal if no
2778 \type{CheckerException} is thrown. Many of the checkers either extends the
2779 \type{PropertyCollector} or utilizes one or more property collectors to verify
2780 some criteria. The checkers registered with the \type{LegalStatementsChecker}
2781 are described next. They are run in the order presented below.
2783 \subsection{The CallToProtectedOrPackagePrivateMethodChecker}
2784 This checker is designed to prevent an error that can occur in situations where
2785 a method is declared in one class, but overridden in another. If a text
2786 selection contains a call to a method like this, and the seletion is extracted
2787 to a new method, the subsequent movement of this method could cause the code to
2790 The code breaks in situations where the method call in the selection is to a
2791 method that has the \code{protected} modifier, or it does not have any access
2792 modifiers, i.e. it is package-private. The method is not public, so the
2793 \MoveMethod refactoring must make it public, making the moved method able to
2794 call it from its new location. The problem is that the, now public, method is
2795 overridden in a subclass, where it has a protected or package-private status.
2796 This makes the compiler complain that the subclass is trying to reduce the
2797 visibility of a method declared in its superclass. This is not allowed in Java,
2798 and for good reasons. It would make it possible to make a subclass that could
2799 not be a substitute for its superclass.
2801 The workings of the \type{CallToProtectedOrPackagePrivateMethod\-Checker} is
2802 therefore very simple. It looks for calls to methods that are either protected
2803 or package-private within the selection, and throws an
2804 \type{IllegalExpressionFoundException} if one is found.
2806 The problem this checker helps to avoid, is a little subtle. The problem does
2807 not arise in the class where the change is done, but in a class derived from it.
2808 This shows that classes acting as superclasses are especially fragile to
2809 introducing errors in the context of automated refactoring. This is also shown
2810 in bug\ldots \todoin{File Eclipse bug report}
2812 \subsection{The InstantiationOfNonStaticInnerClassChecker}
2813 When a non-static inner class is instatiated, this must happen in the scope of
2814 its declaring class. This is because it must have access to the members of the
2815 declaring class. If the inner class is public, it is possible to instantiate it
2816 through an instance of its declaring class, but this is not handled by the
2817 \type{MoveInstanceMethodProcessor} in Eclipse when moving a method. Therefore,
2818 performing a move on a method that instantiates a non-static inner class, will
2819 break the code if the instantiation is not handled properly. For this reason,
2820 the \type{InstantiationOfNonStaticInnerClassChecker} does not validate
2821 selections that contains instantiations of non-static inner classes. This
2822 problem is also related to bug\ldots \todoin{File Eclipse bug report}
2824 \subsection{The EnclosingInstanceReferenceChecker}
2825 The purpose of this checker is to verify that the names in a selection is not
2826 referencing any enclosing instances. This is for making sure that all references
2827 is legal in a method that is to be moved. Theoretically, some situations could
2828 be easily solved my passing a reference to the referenced class with the moved
2829 method (e.g. when calling public methods), but the dependency on the
2830 \type{MoveInstanceMethodProcessor} prevents this.
2833 \typewithref{no.uio.ifi.refaktor.analyze.analyzers}{EnclosingInstanceReferenceChecker}
2834 is a modified version of the
2835 \typewithref{org.eclipse.jdt.internal.corext.refactoring.structure.MoveInstanceMethod\-Processor}{EnclosingInstanceReferenceFinder}
2836 from the \type{MoveInstanceMethodProcessor}. Wherever the
2837 \type{EnclosingInstanceReferenceFinder} would create a fatal error status, the
2838 checker throws a \type{CheckerException}.
2840 It works by first finding all of the enclosing types of a selection. Thereafter
2841 it visits all its simple names to check that they are not references to
2842 variables or methods declared in any of the enclosing types. In addition the
2843 checker visits \var{this}-expressions to verify that no such expressions is
2844 qualified with any name.
2846 \subsection{The ReturnStatementsChecker}\label{returnStatementsChecker}
2847 The checker for return statements is meant to verify that if a text selection
2848 contains a return statement, then every possible execution path within the
2849 selection ends in a return statement. This property is important regarding the
2850 \ExtractMethod refactoring. If it holds, it means that a method could be
2851 extracted from the selection, and a call to it could be substituted for the
2852 selection. If the method has a non-void return type, then a call to it would
2853 also be a valid return point for the calling method. If its return value is of
2854 the void type, then the \type{ExtractMethodRefactoring} of \name{Eclipse}
2855 appends an empty return statement to the back of the method call. Therefore, the
2856 analysis does not discriminate on either kinds of return statements, with or
2857 without a return value.
2859 The property description implies that if the selection is free from return
2860 statements, then the checker validates. So this is the first thing the checker
2863 If the checker proceedes any further, it is because the selection contains one
2864 or more return statements. The next test is therefore to check if the last
2865 statement of the selection ends in either a return or a throw statement. If the
2866 last statement of the selection ends in a return statement, then all execution
2867 paths within the selection should end in either this, or another, return
2868 statement. This is also true for a throw statement, since it causes an immediate
2869 exit from the current block, together with all outer blocks in its control flow
2870 that does not catch the thrown exception.
2872 Return statements can be either explicit or implicit. An \emph{explicit} return
2873 statement is formed by using the \code{return} keyword, while an \emph{implicit}
2874 return statement is a statement that is not formed by the \code{return} keyword,
2875 but must be the last statement of a method that can have any side effects. This
2876 can happen in methods with a void return type. An example is a statement that is
2877 inside one or more blocks. The last statement of a method could for instance be
2878 an if-statement, but the last statement that is executed in the method, and that
2879 can have any side effects, may be located inside the block of the else part of
2882 The responsibility for checking that the last statement of the selection
2883 eventually ends in a return or throw statement, is put on the
2884 \type{LastStatementOfSelectionEndsInReturnOrThrowChecker}. For every node
2885 visited, if it is a statement, it does a test to see if the statement is a
2886 return, a throw or if it is an implicit return statement. If this is the case,
2887 no further checking is done. This checking is done in the \code{preVisit2}
2888 method \see{astVisitor}. If the node is not of a type that is being handled by
2889 its type specific visit method, the checker performs a simple test. If the node
2890 being visited is not the last statement of its parent that is also enclosed by
2891 the selection, an \type{IllegalStatementFoundException} is thrown. This ensures
2892 that all statements are taken care of, one way or the other. It also ensures
2893 that the checker is conservative in the way it checks for legality of the
2896 To examine if a statement is an implicit return statement, the checker first
2897 finds the last statement declared in its enclosing method. If this statement is
2898 the same as the one under investigation, it is considered an implicit return
2899 statement. If the statements are not the same, the checker does a search to see
2900 if statement examined is also the last statement of the method that can be
2901 reached. This includes the last statement of a block statement, a labeled
2902 statement, a synchronized statement or a try statement, that in turn is the last
2903 statement enclosed by the statement types listed. This search goes through all
2904 the parents of a statement until a statement is found that is not one of the
2905 mentioned acceptable parent statements. If the search ends in a method
2906 declaration, then the statement is considered to be the last reachable statement
2907 of the method, and thus also an implicit return statement.
2909 There are two kinds of statements that are handled explicitly. It is
2910 if-statements and try-statements. Block, labeled and do-statements are handled
2911 by fall-through to the other two. Do-statements are considered equal to blocks
2912 in this context, since their bodies are always evaluated at least one time. If-
2913 and try-statements are visited only if they are the last node of their parent
2914 within the selection.
2916 For if-statements, the rule is that if the then-part does not contain any return
2917 or throw statements, it is considered illegal. If it does contain a return or
2918 throw, its else-part is checked. If the else-part is non-existent, or it does
2919 not contain any return or throw statements, it is considered illegal. If the
2920 statement is not regarded illegal, its children are visited.
2922 Try-statements are handled much the same way as if-statements. Its body must
2923 contain a return or throw. The same applies to its catch clauses and finally
2926 If the checker does not complain at any point, the selection is considered valid
2927 with respect to return statements.
2929 \subsection{The AmbiguousReturnValueChecker}
2930 This checker verifies that there are no \emph{ambiguous return statements} in a
2931 selection. The problem with ambiguous return statements arise when a selection
2932 is chosen to be extracted into a new method, but it needs to return more than
2933 one value from that method. This problem occurs in two situations. The first
2934 situation arise when there is more than one local variable that is both assigned
2935 to within a selection and also referenced after the selection. The other
2936 situation occur when there is only one such assignment, but there is also one or
2937 more return statements in the selection.
2939 First the checker needs to collect some data. Those data are the binding keys
2940 for all simple names that are assigned to within the selection, including
2941 variable declarations, but excluding fields. The checker also collects whether
2942 there exists a return statement in the selection or not. No further checks of
2943 return statements are needed, since, at this point, the selection is already
2944 checked for illegal return statements \see{returnStatementsChecker}.
2946 After the binding keys of the assignees are collected, the checker searches the
2947 part of the enclosing method that is after the selection for references whose
2948 binding keys are among the collected keys. If more than one unique referral is
2949 found, or only one referral is found, but the selection also contains a return
2950 statement, we have a situation with an ambiguous return value, and an exception
2953 %\todoin{Explain why we do not need to consider variables assigned inside
2954 %local/anonymous classes. (The referenced variables need to be final and so
2957 \subsection{The IllegalStatementsChecker}
2958 This checker is designed to check for illegal statements.
2960 Any use of the \var{super} keyword is prohibited, since its meaning is altered
2961 when moving a method to another class.
2963 For a \emph{break} statement, there is two situations to consider: A break
2964 statement with or without a label. If the break statement has a label, it is
2965 checked that whole of the labeled statement is inside the selection. Since a
2966 label does not have any binding information, we have to search upwards in the
2967 AST to find the \type{LabeledStatement} that corresponds to the label from the
2968 break statement, and check that it is contained in the selection. If the break
2969 statement does not have a label attached to it, it is checked that its innermost
2970 enclosing loop or switch statement also is inside the selection.
2972 The situation for a \emph{continue} statement is the same as for a break
2973 statement, except that it is not allowed inside switch statements.
2975 Regarding \emph{assignments}, two types of assignments is allowed: Assignment to
2976 a non-final variable and assignment to an array access. All other assignments is
2979 \todoin{Finish\ldots}
2982 \chapter{Benchmarking}
2983 \todoin{Better name than ``benchmarking''?}
2984 This part of the master project is located in the \name{Eclipse} project
2985 \code{no.uio.ifi.refaktor.benchmark}. The purpose of it is to run the equivalent
2986 of the \type{SearchBasedExtractAndMoveMethodChanger}
2987 \see{searchBasedExtractAndMoveMethodChanger} over a larger software project,
2988 both to test its robustness but also its effect on different software metrics.
2990 \section{The benchmark setup}
2991 The benchmark itself is set up as a \name{JUnit} test case. This is a convenient
2992 setup, and utilizes the \name{JUnit Plugin Test Launcher}. This provides us a
2993 with a fully functional \name{Eclipse} workbench. Most importantly, this gives
2994 us access to the Java Model of \name{Eclipse} \see{javaModel}.
2996 \subsection{The ProjectImporter}
2997 The Java project that is going to be used as the data for the benchmark, must be
2998 imported into the JUnit workspace. This is done by the
2999 \typewithref{no.uio.ifi.refaktor.benchmark}{ProjectImporter}. The importer
3000 require the absolute path to the project description file. It is named
3001 \code{.project} and is located at the root of the project directory.
3003 The project description is loaded to find the name of the project to be
3004 imported. The project that shall be the destination for the import is created in
3005 the workspace, on the base of the name from the description. Then an import
3006 operation is created, based on both the source and destination information. The
3007 import operation is run to perform the import.
3009 I have found no simple API call to accomplish what the importer does, which
3010 tells me that it may not be too many people performing this particular action.
3011 The solution to the problem was found on \name{Stack
3012 Overflow}\footnote{\url{https://stackoverflow.com/questions/12401297}}. It
3013 contains enough dirty details to be considered inconvenient to use, if not
3014 wrapping it in a class like my \type{ProjectImporter}. One would probably have
3015 to delve into the source code for the import wizard to find out how the import
3016 operation works, if no one had already done it.
3018 \section{Statistics}
3019 Statistics for the analysis and changes is captured by the
3020 \typewithref{no.uio.ifi.refaktor.aspects}{StatisticsAspect}. This an
3021 \emph{aspect} written in \name{AspectJ}.
3023 \subsection{AspectJ}
3024 \name{AspectJ}\footnote{\url{http://eclipse.org/aspectj/}} is an extension to
3025 the Java language, and facilitates combining aspect-oriented programming with
3026 the object-oriented programming in Java.
3028 Aspect-oriented programming is a programming paradigm that is meant to isolate
3029 so-called \emph{cross-cutting concerns} into their own modules. These
3030 cross-cutting concerns are functionalities that spans over multiple classes, but
3031 may not belong naturally in any of them. It can be functionality that does not
3032 concern the business logic of an application, and thus may be a burden when
3033 entangled with parts of the source code it does not really belong. Examples
3034 include logging, debugging, optimization and security.
3036 Aspects are interacting with other modules by defining advices. The concept of
3037 an \emph{advice} is known from both aspect-oriented and functional
3038 programming\citing{wikiAdvice2014}. It is a function that modifies another
3039 function when the latter is run. An advice in AspectJ is somewhat similar to a
3040 method in Java. It is meant to alter the behavior of other methods, and contains
3041 a body that is executed when it is applied.
3043 An advice can be applied at a defined \emph{pointcut}. A pointcut picks out one
3044 or more \emph{join points}. A join point is a well-defined point in the
3045 execution of a program. It can occur when calling a method defined for a
3046 particular class, when calling all methods with the same name,
3047 accessing/assigning to a particular field of a given class and so on. An advice
3048 can be declared to run both before, after returning from a pointcut, when there
3049 is thrown an exception in the pointcut or after the pointcut either returns or
3050 throws an exception. In addition to picking out join points, a pointcut can
3051 also bind variables from its context, so they can be accessed in the body of an
3052 advice. An example of a pointcut and an advice is found in
3053 \myref{lst:aspectjExample}.
3056 \begin{minted}{aspectj}
3057 pointcut methodAnalyze(
3058 SearchBasedExtractAndMoveMethodAnalyzer analyzer) :
3059 call(* SearchBasedExtractAndMoveMethodAnalyzer.analyze())
3060 && target(analyzer);
3062 after(SearchBasedExtractAndMoveMethodAnalyzer analyzer) :
3063 methodAnalyze(analyzer) {
3064 statistics.methodCount++;
3065 debugPrintMethodAnalysisProgress(analyzer.method);
3068 \caption{An example of a pointcut named \method{methodAnalyze},
3069 and an advice defined to be applied after it has occurred.}
3070 \label{lst:aspectjExample}
3073 \subsection{The Statistics class}
3074 The statistics aspect stores statistical information in an object of type
3075 \type{Statistics}. As of now, the aspect needs to be initialized at the point in
3076 time where it is desired that it starts its data gathering. At any point in time
3077 the statistics aspect can be queried for a snapshot of the current statistics.
3079 The \type{Statistics} class also include functionality for generating a report
3080 of its gathered statistics. The report can be given either as a string or it can
3081 be written to a file.
3083 \subsection{Advices}
3084 The statistics aspect contains advices for gathering statistical data from
3085 different parts of the benchmarking process. It captures statistics from both
3086 the analysis part and the execution part of the composite \ExtractAndMoveMethod
3089 For the analysis part, there are advices to count the number of text selections
3090 analyzed and the number of methods, types, compilation units and packages
3091 analyzed. There are also advices that counts for how many of the methods there
3092 is found a selection that is a candidate for the refactoring, and for how many
3093 methods there is not.
3095 There exists advices for counting both the successful and unsuccessful
3096 executions of all the refactorings. Both for the \ExtractMethod and \MoveMethod
3097 refactorings in isolation, as well as for the combination of them.
3099 \section{Optimizations}
3100 When looking for optimizations to make for the benchmarking process, I used the
3101 \name{VisualVM}\footnote{\url{http://visualvm.java.net/}} for the Java Virtual
3102 Machine to both profile the application and also to make memory dumps of its
3105 \subsection{Caching}
3106 When profiling the benchmark process before making any optimizations, it early
3107 became apparent that the parsing of source code was a place to direct attention
3108 towards. This discovery was done when only \emph{analyzing} source code, before
3109 trying to do any \emph{manipulation} of it. Caching of the parsed ASTs seemed
3110 like the best way to save some time, as expected. With only a simple cache of
3111 the most recently used AST, the analysis time was speeded up by a factor of
3113 20. This number depends a little upon which type of system the analysis was
3116 The caching is managed by a cache manager, that now, by default, utilizes the
3117 not so well known feature of Java called a \emph{soft reference}. Soft
3118 references are best explained in the context of weak references. A \emph{weak
3119 reference} is a reference to an object instance that is only guaranteed to
3120 persist as long as there is a \emph{strong reference} or a soft reference
3121 referring the same object. If no such reference is found, its referred object is
3122 garbage collected. A strong reference is basically the same as a regular Java
3123 reference. A soft reference has the same guarantees as a week reference when it
3124 comes to its relation to strong references, but it is not necessarily garbage
3125 collected whenever there exists no strong references to it. A soft reference
3126 \emph{may} reside in memory as long as the JVM has enough free memory in the
3127 heap. A soft reference will therefore usually perform better than a weak
3128 reference when used for simple caching and similar tasks. The way to use a
3129 soft/weak reference is to as it for its referent. The return value then has to
3130 be tested to check that it is not \var{null}. For the basic usage of soft
3131 references, see \myref{lst:softReferenceExample}. For a more thorough
3132 explanation of weak references in general, see\citing{weakRef2006}.
3135 \begin{minted}{java}
3137 Object strongRef = new Object();
3140 SoftReference<Object> softRef =
3141 new SoftReference<Object>(new Object());
3143 // Using the soft reference
3144 Object obj = softRef.get();
3149 \caption{Showing the basic usage of soft references. Weak references is used the
3150 same way. {\footnotesize (The references are part of the \code{java.lang.ref}
3152 \label{lst:softReferenceExample}
3155 The cache based on soft references has no limit for how many ASTs it caches. It
3156 is generally not advisable to keep references to ASTs for prolonged periods of
3157 time, since they are expensive structures to hold on to. For regular plugin
3158 development, \name{Eclipse} recommends not creating more than one AST at a time to
3159 limit memory consumption. Since the benchmarking has nothing to do with user
3160 experience, and throughput is everything, these advices are intentionally
3161 ignored. This means that during the benchmarking process, the target \name{Eclipse}
3162 application may very well work close to its memory limit for the heap space for
3163 long periods during the benchmark.
3165 \subsection{Memento}
3168 \chapter{Eclipse Bugs Found}
3169 \newcommand{\submittedBugReport}[1]{The submitted bug report can be found on
3172 \section{Eclipse bug 420726: Code is broken when moving a method that is
3173 assigning to the parameter that is also the move
3174 destination}\label{eclipse_bug_420726}
3176 was found when analyzing what kinds of names that was to be considered as
3177 \emph{unfixes} \see{unfixes}.
3179 \subsection{The bug}
3180 The bug emerges when trying to move a method from one class to another, and when
3181 the target for the move (must be a variable, local or field) is both a parameter
3182 variable and also is assigned to within the method body. \name{Eclipse} allows this to
3183 happen, although it is the sure path to a compilation error. This is because we
3184 would then have an assignment to a \var{this} expression, which is not allowed
3186 \submittedBugReport{https://bugs.eclipse.org/bugs/show\_bug.cgi?id=420726}
3188 \subsection{The solution}
3189 The solution to this problem is to add all simple names that are assigned to in
3190 a method body to the set of unfixes.
3192 \section{Eclipse bug 429416: IAE when moving method from anonymous
3193 class}\label{eclipse_bug_429416}
3195 this bug during a batch change on the \type{org.eclipse.jdt.ui} project.
3197 \subsection{The bug}
3198 This bug surfaces when trying to use the \refa{Move Method} refactoring to move a
3199 method from an anonymous class to another class. This happens both for my
3200 simulation as well as in \name{Eclipse}, through the user interface. It only occurs
3201 when \name{Eclipse} analyzes the program and finds it necessary to pass an instance of
3202 the originating class as a parameter to the moved method. I.e. it want to pass a
3203 \var{this} expression. The execution ends in an
3204 \typewithref{java.lang}{IllegalArgumentException} in
3205 \typewithref{org.eclipse.jdt.core.dom}{SimpleName} and its
3206 \method{setIdentifier(String)} method. The simple name is attempted created in
3208 \methodwithref{org.eclipse.jdt.internal.corext.refactoring.structure.\\MoveInstanceMethodProcessor}{createInlinedMethodInvocation}
3209 so the \type{MoveInstanceMethodProcessor} was early a clear suspect.
3211 The \method{createInlinedMethodInvocation} is the method that creates a method
3212 invocation where the previous invocation to the method that was moved was. From
3213 its code it can be read that when a \var{this} expression is going to be passed
3214 in to the invocation, it shall be qualified with the name of the original
3215 method's declaring class, if the declaring class is either an anonymous class or
3216 a member class. The problem with this, is that an anonymous class does not have
3217 a name, hence the term \emph{anonymous} class! Therefore, when its name, an
3218 empty string, is passed into
3219 \methodwithref{org.eclipse.jdt.core.dom.AST}{newSimpleName} it all ends in an
3220 \type{IllegalArgumentException}.
3221 \submittedBugReport{https://bugs.eclipse.org/bugs/show\_bug.cgi?id=429416}
3223 \subsection{How I solved the problem}
3224 Since the \type{MoveInstanceMethodProcessor} is instantiated in the
3225 \typewithref{no.uio.ifi.refaktor.change.executors}{MoveMethod\-RefactoringExecutor},
3226 and only need to be a
3227 \typewithref{org.eclipse.ltk.core.refactoring.participants}{MoveProcessor}, I
3228 was able to copy the code for the original move processor and modify it so that
3229 it works better for me. It is now called
3230 \typewithref{no.uio.ifi.refaktor.change.processors}{ModifiedMoveInstanceMethodProcessor}.
3231 The only modification done (in addition to some imports and suppression of
3232 warnings), is in the \method{createInlinedMethodInvocation}. When the declaring
3233 class of the method to move is anonymous, the \var{this} expression in the
3234 parameter list is not qualified with the declaring class' (empty) name.
3236 \section{Eclipse bug 429954: Extracting statement with reference to local type
3237 breaks code}\label{eclipse_bug_429954}
3239 was discovered when doing some changes to the way unfixes is computed.
3241 \subsection{The bug}
3242 The problem is that \name{Eclipse} is allowing selections that references variables of
3243 local types to be extracted. When this happens the code is broken, since the
3244 extracted method must take a parameter of a local type that is not in the
3245 methods scope. The problem is illustrated in
3246 \myref{lst:extractMethod_LocalClass}, but there in another setting.
3247 \submittedBugReport{https://bugs.eclipse.org/bugs/show\_bug.cgi?id=429954}
3249 \subsection{Actions taken}
3250 There are no actions directly springing out of this bug, since the Extract
3251 Method refactoring cannot be meant to be this way. This is handled on the
3252 analysis stage of our \refa{Extract and Move Method} refactoring. So names representing
3253 variables of local types is considered unfixes \see{unfixes}.
3254 \todoin{write more when fixing this in legal statements checker}
3256 \chapter{Related Work}
3258 \section{The compositional paradigm of refactoring}
3259 This paradigm builds upon the observation of Vakilian et
3260 al.\citing{vakilian2012}, that of the many automated refactorings existing in
3261 modern IDEs, the simplest ones are dominating the usage statistics. The report
3262 mainly focuses on \name{Eclipse} as the tool under investigation.
3264 The paradigm is described almost as the opposite of automated composition of
3265 refactorings \see{compositeRefactorings}. It works by providing the programmer
3266 with easily accessible primitive refactorings. These refactorings shall be
3267 accessed via keyboard shortcuts or quick-assist menus\footnote{Think
3268 quick-assist with Ctrl+1 in \name{Eclipse}} and be promptly executed, opposed to in the
3269 currently dominating wizard-based refactoring paradigm. They are meant to
3270 stimulate composing smaller refactorings into more complex changes, rather than
3271 doing a large upfront configuration of a wizard-based refactoring, before
3272 previewing and executing it. The compositional paradigm of refactoring is
3273 supposed to give control back to the programmer, by supporting \himher with an
3274 option of performing small rapid changes instead of large changes with a lesser
3275 degree of control. The report authors hope this will lead to fewer unsuccessful
3276 refactorings. It also could lower the bar for understanding the steps of a
3277 larger composite refactoring and thus also help in figuring out what goes wrong
3278 if one should choose to op in on a wizard-based refactoring.
3280 Vakilian and his associates have performed a survey of the effectiveness of the
3281 compositional paradigm versus the wizard-based one. They claim to have found
3282 evidence of that the \emph{compositional paradigm} outperforms the
3283 \emph{wizard-based}. It does so by reducing automation, which seem
3284 counterintuitive. Therefore they ask the question ``What is an appropriate level
3285 of automation?'', and thus questions what they feel is a rush toward more
3286 automation in the software engineering community.