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{glossaries}
20 \usepackage[style=alphabetic,backend=bibtex]{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{\definition}[1]{\begin{wordDef}#1\end{wordDef}}
46 \newcommand{\see}[1]{(see \myref{#1})}
47 \newcommand{\explanation}[3]{\noindent\textbf{\textit{#1}}\\*\emph{When:}
48 #2\\*\emph{How:} #3\\*[-7px]}
50 %\newcommand{\type}[1]{\lstinline{#1}}
51 \newcommand{\code}[1]{\texttt{\textbf{#1}}}
52 \newcommand{\type}[1]{\code{#1}}
53 \newcommand{\typeref}[1]{\footnote{\type{#1}}}
54 \newcommand{\typewithref}[2]{\type{#2}\typeref{#1.#2}}
55 \newcommand{\method}[1]{\type{#1}}
56 \newcommand{\methodref}[2]{\footnote{\type{#1}\method{\##2()}}}
57 \newcommand{\methodwithref}[2]{\method{#2}\footnote{\type{#1}\method{\##2()}}}
58 \newcommand{\var}[1]{\type{#1}}
60 \newcommand{\refactoring}[1]{\emph{#1}}
61 \newcommand{\ExtractMethod}{\refactoring{Extract Method}\xspace}
62 \newcommand{\MoveMethod}{\refactoring{Move Method}\xspace}
63 \newcommand{\ExtractAndMoveMethod}{\refactoring{Extract and Move Method}\xspace}
65 \newcommand\todoin[2][]{\todo[inline, caption={#2}, #1]{
66 \begin{minipage}{\textwidth-4pt}#2\end{minipage}}}
68 \title{Automated Composition of Refactorings}
69 \subtitle{Composing the Extract and Move Method refactorings in Eclipse}
70 \author{Erlend Kristiansen}
72 \bibliography{bibliography/master-thesis-erlenkr-bibliography}
74 % UML comment in TikZ:
75 % ref: https://tex.stackexchange.com/questions/103688/folded-paper-shape-tikz
77 \pgfdeclareshape{umlcomment}{
78 \inheritsavedanchors[from=rectangle] % this is nearly a rectangle
79 \inheritanchorborder[from=rectangle]
80 \inheritanchor[from=rectangle]{center}
81 \inheritanchor[from=rectangle]{north}
82 \inheritanchor[from=rectangle]{south}
83 \inheritanchor[from=rectangle]{west}
84 \inheritanchor[from=rectangle]{east}
85 % ... and possibly more
86 \backgroundpath{% this is new
87 % store lower right in xa/ya and upper right in xb/yb
88 \southwest \pgf@xa=\pgf@x \pgf@ya=\pgf@y
89 \northeast \pgf@xb=\pgf@x \pgf@yb=\pgf@y
90 % compute corner of ‘‘flipped page’’
91 \pgf@xc=\pgf@xb \advance\pgf@xc by-10pt % this should be a parameter
92 \pgf@yc=\pgf@yb \advance\pgf@yc by-10pt
94 \pgfpathmoveto{\pgfpoint{\pgf@xa}{\pgf@ya}}
95 \pgfpathlineto{\pgfpoint{\pgf@xa}{\pgf@yb}}
96 \pgfpathlineto{\pgfpoint{\pgf@xc}{\pgf@yb}}
97 \pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@yc}}
98 \pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@ya}}
101 \pgfpathmoveto{\pgfpoint{\pgf@xc}{\pgf@yb}}
102 \pgfpathlineto{\pgfpoint{\pgf@xc}{\pgf@yc}}
103 \pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@yc}}
104 \pgfpathlineto{\pgfpoint{\pgf@xc}{\pgf@yc}}
109 \tikzstyle{comment}=[%
128 \todoin{\textbf{Remove all todos (including list) before delivery/printing!!!
129 Can be done by removing ``draft'' from documentclass.}}
130 \todoin{Write abstract}
138 The discussions in this report must be seen in the context of object oriented
139 programming languages, and Java in particular, since that is the language in
140 which most of the examples will be given. All though the techniques discussed
141 may be applicable to languages from other paradigms, they will not be the
142 subject of this report.
146 \chapter{What is Refactoring?}
148 This question is best answered by first defining the concept of a
149 \emph{refactoring}, what it is to \emph{refactor}, and then discuss what aspects
150 of programming make people want to refactor their code.
152 \section{Defining refactoring}
153 Martin Fowler, in his classic book on refactoring\citing{refactoring}, defines a
154 refactoring like this:
157 \emph{Refactoring} (noun): a change made to the internal
158 structure\footnote{The structure observable by the programmer.} of software to
159 make it easier to understand and cheaper to modify without changing its
160 observable behavior.~\cite[p.~53]{refactoring}
163 \noindent This definition assigns additional meaning to the word
164 \emph{refactoring}, beyond the composition of the prefix \emph{re-}, usually
165 meaning something like ``again'' or ``anew'', and the word \emph{factoring},
166 that can mean to isolate the \emph{factors} of something. Here a \emph{factor}
167 would be close to the mathematical definition of something that divides a
168 quantity, without leaving a remainder. Fowler is mixing the \emph{motivation}
169 behind refactoring into his definition. Instead it could be more refined, formed
170 to only consider the \emph{mechanical} and \emph{behavioral} aspects of
171 refactoring. That is to factor the program again, putting it together in a
172 different way than before, while preserving the behavior of the program. An
173 alternative definition could then be:
175 \definition{A \emph{refactoring} is a transformation
176 done to a program without altering its external behavior.}
178 From this we can conclude that a refactoring primarily changes how the
179 \emph{code} of a program is perceived by the \emph{programmer}, and not the
180 \emph{behavior} experienced by any user of the program. Although the logical
181 meaning is preserved, such changes could potentially alter the program's
182 behavior when it comes to performance gain or -penalties. So any logic depending
183 on the performance of a program could make the program behave differently after
186 In the extreme case one could argue that \emph{software obfuscation} is
187 refactoring. Software obfuscation makes source code harder to read and analyze,
188 while preserving its semantics. It is often used to protect proprietary
189 software. It restrains uninvited viewers, so they have a hard time analyzing
190 code that they are not supposed to know how works. This could be a problem when
191 using a language that is possible to decompile, such as Java.
193 Obfuscation could be done composing many, more or less randomly chosen,
194 refactorings. Then the question arises whether it can be called a
195 \emph{composite refactoring} or not \see{compositeRefactorings}? The answer is
196 not obvious. First, there is no way to describe the mechanics of software
197 obfuscation, because there are infinitely many ways to do that. Second,
198 obfuscation can be thought of as \emph{one operation}: Either the code is
199 obfuscated, or it is not. Third, it makes no sense to call software obfuscation
200 \emph{a refactoring}, since it holds different meaning to different people.
202 This last point is important, since one of the motivations behind defining
203 different refactorings, is to establish a \emph{vocabulary} for software
204 professionals to use when reasoning about and discussing programs, similar to
205 the motivation behind \emph{design patterns}\citing{designPatterns}. A design
206 pattern is a named abstraction, that is meant to solve a general design problem.
207 It describes the key aspects of a common problem and identifies its
208 participators and how they collaborate.
211 So for describing \emph{software obfuscation}, it might be more appropriate to
212 define what you do when performing it rather than precisely defining its
213 mechanics in terms of other refactorings.
216 \section{The etymology of 'refactoring'}
217 It is a little difficult to pinpoint the exact origin of the word
218 ``refactoring'', as it seems to have evolved as part of a colloquial
219 terminology, more than a scientific term. There is no authoritative source for a
220 formal definition of it.
222 According to Martin Fowler\citing{etymology-refactoring}, there may also be more
223 than one origin of the word. The most well-known source, when it comes to the
224 origin of \emph{refactoring}, is the
225 Smalltalk\footnote{\label{footNote}Programming language} community and their
226 infamous \emph{Refactoring
227 Browser}\footnote{\url{http://st-www.cs.illinois.edu/users/brant/Refactory/RefactoringBrowser.html}}
228 described in the article \emph{A Refactoring Tool for
229 Smalltalk}\citing{refactoringBrowser1997}, published in 1997.
230 Allegedly\citing{etymology-refactoring}, the metaphor of factoring programs was
231 also present in the Forth\textsuperscript{\ref{footNote}} community, and the
232 word ``refactoring'' is mentioned in a book by Leo Brodie, called \emph{Thinking
233 Forth}\citing{brodie2004}, first published in 1984\footnote{\emph{Thinking
234 Forth} was first published in 1984 by the \emph{Forth Interest Group}. Then it
235 was reprinted in 1994 with minor typographical corrections, before it was
236 transcribed into an electronic edition typeset in \LaTeX\ and published under a
237 Creative Commons licence in
238 2004. The edition cited here is the 2004 edition, but the content should
239 essentially be as in 1984.}. The exact word is only printed one
240 place~\cite[p.~232]{brodie2004}, but the term \emph{factoring} is prominent in
241 the book, that also contains a whole chapter dedicated to (re)factoring, and how
242 to keep the (Forth) code clean and maintainable.
245 \ldots good factoring technique is perhaps the most important skill for a
246 Forth programmer.~\cite[p.~172]{brodie2004}
249 \noindent Brodie also express what \emph{factoring} means to him:
252 Factoring means organizing code into useful fragments. To make a fragment
253 useful, you often must separate reusable parts from non-reusable parts. The
254 reusable parts become new definitions. The non-reusable parts become arguments
255 or parameters to the definitions.~\cite[p.~172]{brodie2004}
258 Fowler claims that the usage of the word \emph{refactoring} did not pass between
259 the \emph{Forth} and \emph{Smalltalk} communities, but that it emerged
260 independently in each of the communities.
262 \section{Motivation -- Why people refactor}
263 There are many reasons why people want to refactor their programs. They can for
264 instance do it to remove duplication, break up long methods or to introduce
265 design patterns into their software systems. The shared trait for all these are
266 that peoples' intentions are to make their programs \emph{better}, in some
267 sense. But what aspects of their programs are becoming improved?
269 As just mentioned, people often refactor to get rid of duplication. They are
270 moving identical or similar code into methods, and are pushing methods up or
271 down in their class hierarchies. They are making template methods for
272 overlapping algorithms/functionality, and so on. It is all about gathering what
273 belongs together and putting it all in one place. The resulting code is then
274 easier to maintain. When removing the implicit coupling\footnote{When
275 duplicating code, the duplicate pieces of code might not be coupled, apart
276 from representing the same functionality. So if this functionality is going to
277 change, it might need to change in more than one place, thus creating an
278 implicit coupling between multiple pieces of code.} between code snippets, the
279 location of a bug is limited to only one place, and new functionality need only
280 to be added to this one place, instead of a number of places people might not
283 A problem you often encounter when programming, is that a program contains a lot
284 of long and hard-to-grasp methods. It can then help to break the methods into
285 smaller ones, using the \ExtractMethod refactoring\citing{refactoring}. Then you
286 may discover something about a program that you were not aware of before;
287 revealing bugs you did not know about or could not find due to the complex
288 structure of your program. \todo{Proof?} Making the methods smaller and giving
289 good names to the new ones clarifies the algorithms and enhances the
290 \emph{understandability} of the program \see{magic_number_seven}. This makes
291 refactoring an excellent method for exploring unknown program code, or code that
292 you had forgotten that you wrote.
294 Most primitive refactorings are simple, and usually involves moving code
295 around\citing{kerievsky2005}. The motivation behind them may first be revealed
296 when they are combined into larger --- higher level --- refactorings, called
297 \emph{composite refactorings} \see{compositeRefactorings}. Often the goal of
298 such a series of refactorings is a design pattern. Thus the design can
299 \emph{evolve} throughout the lifetime of a program, as opposed to designing
300 up-front. It is all about being structured and taking small steps to improve a
303 Many software design pattern are aimed at lowering the coupling between
304 different classes and different layers of logic. One of the most famous is
305 perhaps the \emph{Model-View-Controller}\citing{designPatterns} pattern. It is
306 aimed at lowering the coupling between the user interface, the business logic
307 and the data representation of a program. This also has the added benefit that
308 the business logic could much easier be the target of automated tests, thus
309 increasing the productivity in the software development process.
311 Another effect of refactoring is that with the increased separation of concerns
312 coming out of many refactorings, the \emph{performance} can be improved. When
313 profiling programs, the problematic parts are narrowed down to smaller parts of
314 the code, which are easier to tune, and optimization can be performed only where
315 needed and in a more effective way\citing{refactoring}.
317 Last, but not least, and this should probably be the best reason to refactor, is
318 to refactor to \emph{facilitate a program change}. If one has managed to keep
319 one's code clean and tidy, and the code is not bloated with design patterns that
320 are not ever going to be needed, then some refactoring might be needed to
321 introduce a design pattern that is appropriate for the change that is going to
324 Refactoring program code --- with a goal in mind --- can give the code itself
325 more value. That is in the form of robustness to bugs, understandability and
326 maintainability. Having robust code is an obvious advantage, but
327 understandability and maintainability are both very important aspects of
328 software development. By incorporating refactoring in the development process,
329 bugs are found faster, new functionality is added more easily and code is easier
330 to understand by the next person exposed to it, which might as well be the
331 person who wrote it. The consequence of this, is that refactoring can increase
332 the average productivity of the development process, and thus also add to the
333 monetary value of a business in the long run. The perspective on productivity
334 and money should also be able to open the eyes of the many nearsighted managers
335 that seldom see beyond the next milestone.
337 \section{The magical number seven}\label{magic_number_seven}
338 The article \emph{The magical number seven, plus or minus two: some limits on
339 our capacity for processing information}\citing{miller1956} by George A.
340 Miller, was published in the journal \emph{Psychological Review} in 1956. It
341 presents evidence that support that the capacity of the number of objects a
342 human being can hold in its working memory is roughly seven, plus or minus two
343 objects. This number varies a bit depending on the nature and complexity of the
344 objects, but is according to Miller ``\ldots never changing so much as to be
347 Miller's article culminates in the section called \emph{Recoding}, a term he
348 borrows from communication theory. The central result in this section is that by
349 recoding information, the capacity of the amount of information that a human can
350 process at a time is increased. By \emph{recoding}, Miller means to group
351 objects together in chunks, and give each chunk a new name that it can be
355 \ldots recoding is an extremely powerful weapon for increasing the amount of
356 information that we can deal with.~\cite[p.~95]{miller1956}
359 By organizing objects into patterns of ever growing depth, one can memorize and
360 process a much larger amount of data than if it were to be represented as its
361 basic pieces. This grouping and renaming is analogous to how many refactorings
362 work, by grouping pieces of code and give them a new name. Examples are the
363 fundamental \ExtractMethod and \refactoring{Extract Class}
364 refactorings\citing{refactoring}.
366 An example from the article addresses the problem of memorizing a sequence of
367 binary digits. The example presented here is a slightly modified version of the
368 one presented in the original article\citing{miller1956}, but it preserves the
369 essense of it. Let us say we have the following sequence of
370 16 binary digits: ``1010001001110011''. Most of us will have a hard time
371 memorizing this sequence by only reading it once or twice. Imagine if we instead
372 translate it to this sequence: ``A273''. If you have a background from computer
373 science, it will be obvious that the latter sequence is the first sequence
374 recoded to be represented by digits in base 16. Most people should be able to
375 memorize this last sequence by only looking at it once.
377 Another result from the Miller article is that when the amount of information a
378 human must interpret increases, it is crucial that the translation from one code
379 to another must be almost automatic for the subject to be able to remember the
380 translation, before \heshe is presented with new information to recode. Thus
381 learning and understanding how to best organize certain kinds of data is
382 essential to efficiently handle that kind of data in the future. This is much
383 like when humans learn to read. First they must learn how to recognize letters.
384 Then they can learn distinct words, and later read sequences of words that form
385 whole sentences. Eventually, most of them will be able to read whole books and
386 briefly retell the important parts of its content. This suggest that the use of
387 design patterns is a good idea when reasoning about computer programs. With
388 extensive use of design patterns when creating complex program structures, one
389 does not always have to read whole classes of code to comprehend how they
390 function, it may be sufficient to only see the name of a class to almost fully
391 understand its responsibilities.
394 Our language is tremendously useful for repackaging material into a few chunks
395 rich in information.~\cite[p.~95]{miller1956}
398 Without further evidence, these results at least indicate that refactoring
399 source code into smaller units with higher cohesion and, when needed,
400 introducing appropriate design patterns, should aid in the cause of creating
401 computer programs that are easier to maintain and have code that is easier (and
404 \section{Notable contributions to the refactoring literature}
405 \todoin{Update with more contributions}
408 \item[1992] William F. Opdyke submits his doctoral dissertation called
409 \emph{Refactoring Object-Oriented Frameworks}\citing{opdyke1992}. This
410 work defines a set of refactorings, that are behavior preserving given that
411 their preconditions are met. The dissertation is focused on the automation
413 \item[1999] Martin Fowler et al.: \emph{Refactoring: Improving the Design of
414 Existing Code}\citing{refactoring}. This is maybe the most influential text
415 on refactoring. It bares similarities with Opdykes thesis\citing{opdyke1992}
416 in the way that it provides a catalog of refactorings. But Fowler's book is
417 more about the craft of refactoring, as he focuses on establishing a
418 vocabulary for refactoring, together with the mechanics of different
419 refactorings and when to perform them. His methodology is also founded on
420 the principles of test-driven development.
421 \item[2005] Joshua Kerievsky: \emph{Refactoring to
422 Patterns}\citing{kerievsky2005}. This book is heavily influenced by Fowler's
423 \emph{Refactoring}\citing{refactoring} and the ``Gang of Four'' \emph{Design
424 Patterns}\citing{designPatterns}. It is building on the refactoring
425 catalogue from Fowler's book, but is trying to bridge the gap between
426 \emph{refactoring} and \emph{design patterns} by providing a series of
427 higher-level composite refactorings, that makes code evolve toward or away
428 from certain design patterns. The book is trying to build up the readers
429 intuition around \emph{why} one would want to use a particular design
430 pattern, and not just \emph{how}. The book is encouraging evolutionary
431 design \see{relationToDesignPatterns}.
434 \section{Tool support (for Java)}\label{toolSupport}
435 This section will briefly compare the refatoring support of the three IDEs
436 \emph{Eclipse}\footnote{\url{http://www.eclipse.org/}}, \emph{IntelliJ
437 IDEA}\footnote{The IDE under comparison is the \emph{Community Edition},
438 \url{http://www.jetbrains.com/idea/}} and
439 \emph{NetBeans}\footnote{\url{https://netbeans.org/}}. These are the most
440 popular Java IDEs\citing{javaReport2011}.
442 All three IDEs provide support for the most useful refactorings, like the
443 different extract, move and rename refactorings. In fact, Java-targeted IDEs are
444 known for their good refactoring support, so this did not appear as a big
447 The IDEs seem to have excellent support for the \ExtractMethod refactoring, so
448 at least they have all passed the first ``refactoring
449 rubicon''\citing{fowlerRubicon2001,secondRubicon2012}.
451 Regarding the \MoveMethod refactoring, the \emph{Eclipse} and \emph{IntelliJ}
452 IDEs do the job in very similar manners. In most situations they both do a
453 satisfying job by producing the expected outcome. But they do nothing to check
454 that the result does not break the semantics of the program \see{correctness}.
455 The \emph{NetBeans} IDE implements this refactoring in a somewhat
456 unsophisticated way. For starters, the refactoring's default destination for the
457 move, is the same class as the method already resides in, although it refuses to
458 perform the refactoring if chosen. But the worst part is, that if moving the
459 method \method{f} of the class \type{C} to the class \type{X}, it will break the
460 code. The result is shown in \myref{lst:moveMethod_NetBeans}.
464 \begin{minted}[samepage]{java}
477 \begin{minted}[samepage]{java}
487 \caption{Moving method \method{f} from \type{C} to \type{X}.}
488 \label{lst:moveMethod_NetBeans}
491 NetBeans will try to create code that call the methods \method{m} and \method{n}
492 of \type{X} by accessing them through \var{c.x}, where \var{c} is a parameter of
493 type \type{C} that is added the method \method{f} when it is moved. (This is
494 seldom the desired outcome of this refactoring, but ironically, this ``feature''
495 keeps NetBeans from breaking the code in the example from \myref{correctness}.)
496 If \var{c.x} for some reason is inaccessible to \type{X}, as in this case, the
497 refactoring breaks the code, and it will not compile. NetBeans presents a
498 preview of the refactoring outcome, but the preview does not catch it if the IDE
499 is about break the program.
501 The IDEs under investigation seem to have fairly good support for primitive
502 refactorings, but what about more complex ones, such as \refactoring{Extract
503 Class}\citing{refactoring}? The \refactoring{Extract Class} refactoring works by
504 creating a class, for then to move members to that class and access them from
505 the old class via a reference to the new class. \emph{IntelliJ} handles this in
506 a fairly good manner, although, in the case of private methods, it leaves unused
507 methods behind. These are methods that delegate to a field with the type of the
508 new class, but are not used anywhere. \emph{Eclipse} has added its own quirk to
509 the Extract Class refactoring, and only allows for \emph{fields} to be moved to
510 a new class, \emph{not methods}. This makes it effectively only extracting a
511 data structure, and calling it \refactoring{Extract Class} is a little
512 misleading. One would often be better off with textual extract and paste than
513 using the Extract Class refactoring in Eclipse. When it comes to
514 \emph{NetBeans}, it does not even show an attempt on providing this refactoring.
516 \todoin{Visual Studio (C++/C\#), Smalltalk refactoring browser?,
517 second refactoring rubicon?}
519 \section{The relation to design patterns}\label{relationToDesignPatterns}
521 \emph{Refactoring} and \emph{design patterns} have at least one thing in common,
522 they are both promoted by advocates of \emph{clean code}\citing{cleanCode} as
523 fundamental tools on the road to more maintainable and extendable source code.
526 Design patterns help you determine how to reorganize a design, and they can
527 reduce the amount of refactoring you need to do
528 later.~\cite[p.~353]{designPatterns}
531 Although sometimes associated with
532 over-engineering\citing{kerievsky2005,refactoring}, design patterns are in
533 general assumed to be good for maintainability of source code. That may be
534 because many of them are designed to support the \emph{open/closed principle} of
535 object-oriented programming. The principle was first formulated by Bertrand
536 Meyer, the creator of the Eiffel programming language, like this: ``Modules
537 should be both open and closed.''\citing{meyer1988} It has been popularized,
538 with this as a common version:
541 Software entities (classes, modules, functions, etc.) should be open for
542 extension, but closed for modification.\footnote{See
543 \url{http://c2.com/cgi/wiki?OpenClosedPrinciple} or
544 \url{https://en.wikipedia.org/wiki/Open/closed_principle}}
547 Maintainability is often thought of as the ability to be able to introduce new
548 functionality without having to change too much of the old code. When
549 refactoring, the motivation is often to facilitate adding new functionality. It
550 is about factoring the old code in a way that makes the new functionality being
551 able to benefit from the functionality already residing in a software system,
552 without having to copy old code into new. Then, next time someone shall add new
553 functionality, it is less likely that the old code has to change. Assuming that
554 a design pattern is the best way to get rid of duplication and assist in
555 implementing new functionality, it is reasonable to conclude that a design
556 pattern often is the target of a series of refactorings. Having a repertoire of
557 design patterns can also help in knowing when and how to refactor a program to
558 make it reflect certain desired characteristics.
561 There is a natural relation between patterns and refactorings. Patterns are
562 where you want to be; refactorings are ways to get there from somewhere
563 else.~\cite[p.~107]{refactoring}
566 This quote is wise in many contexts, but it is not always appropriate to say
567 ``Patterns are where you want to be\ldots''. \emph{Sometimes}, patterns are
568 where you want to be, but only because it will benefit your design. It is not
569 true that one should always try to incorporate as many design patterns as
570 possible into a program. It is not like they have intrinsic value. They only add
571 value to a system when they support its design. Otherwise, the use of design
572 patterns may only lead to a program that is more complex than necessary.
575 The overuse of patterns tends to result from being patterns happy. We are
576 \emph{patterns happy} when we become so enamored of patterns that we simply
577 must use them in our code.~\cite[p.~24]{kerievsky2005}
580 This can easily happen when relying largely on up-front design. Then it is
581 natural, in the very beginning, to try to build in all the flexibility that one
582 believes will be necessary throughout the lifetime of a software system.
583 According to Joshua Kerievsky ``That sounds reasonable --- if you happen to be
584 psychic.''~\cite[p.~1]{kerievsky2005} He is advocating what he believes is a
585 better approach: To let software continually evolve. To start with a simple
586 design that meets today's needs, and tackle future needs by refactoring to
587 satisfy them. He believes that this is a more economic approach than investing
588 time and money into a design that inevitably is going to change. By relying on
589 continuously refactoring a system, its design can be made simpler without
590 sacrificing flexibility. To be able to fully rely on this approach, it is of
591 utter importance to have a reliable suit of tests to lean on \see{testing}. This
592 makes the design process more natural and less characterized by difficult
593 decisions that has to be made before proceeding in the process, and that is
594 going to define a project for all of its unforeseeable future.
598 \section{Classification of refactorings}
599 % only interesting refactorings
600 % with 2 detailed examples? One for structured and one for intra-method?
601 % Is replacing Bubblesort with Quick Sort considered a refactoring?
603 \subsection{Structural refactorings}
605 \subsubsection{Primitive refactorings}
608 \explanation{Extract Method}{You have a code fragment that can be grouped
609 together.}{Turn the fragment into a method whose name explains the purpose of
612 \explanation{Inline Method}{A method's body is just as clear as its name.}{Put
613 the method's body into the body of its callers and remove the method.}
615 \explanation{Inline Temp}{You have a temp that is assigned to once with a simple
616 expression, and the temp is getting in the way of other refactorings.}{Replace
617 all references to that temp with the expression}
619 % Moving Features Between Objects
620 \explanation{Move Method}{A method is, or will be, using or used by more
621 features of another class than the class on which it is defined.}{Create a new
622 method with a similar body in the class it uses most. Either turn the old method
623 into a simple delegation, or remove it altogether.}
625 \explanation{Move Field}{A field is, or will be, used by another class more than
626 the class on which it is defined}{Create a new field in the target class, and
627 change all its users.}
630 \explanation{Replace Magic Number with Symbolic Constant}{You have a literal
631 number with a particular meaning.}{Create a constant, name it after the meaning,
632 and replace the number with it.}
634 \explanation{Encapsulate Field}{There is a public field.}{Make it private and
637 \explanation{Replace Type Code with Class}{A class has a numeric type code that
638 does not affect its behavior.}{Replace the number with a new class.}
640 \explanation{Replace Type Code with Subclasses}{You have an immutable type code
641 that affects the behavior of a class.}{Replace the type code with subclasses.}
643 \explanation{Replace Type Code with State/Strategy}{You have a type code that
644 affects the behavior of a class, but you cannot use subclassing.}{Replace the
645 type code with a state object.}
647 % Simplifying Conditional Expressions
648 \explanation{Consolidate Duplicate Conditional Fragments}{The same fragment of
649 code is in all branches of a conditional expression.}{Move it outside of the
652 \explanation{Remove Control Flag}{You have a variable that is acting as a
653 control flag fro a series of boolean expressions.}{Use a break or return
656 \explanation{Replace Nested Conditional with Guard Clauses}{A method has
657 conditional behavior that does not make clear the normal path of
658 execution.}{Use guard clauses for all special cases.}
660 \explanation{Introduce Null Object}{You have repeated checks for a null
661 value.}{Replace the null value with a null object.}
663 \explanation{Introduce Assertion}{A section of code assumes something about the
664 state of the program.}{Make the assumption explicit with an assertion.}
666 % Making Method Calls Simpler
667 \explanation{Rename Method}{The name of a method does not reveal its
668 purpose.}{Change the name of the method}
670 \explanation{Add Parameter}{A method needs more information from its
671 caller.}{Add a parameter for an object that can pass on this information.}
673 \explanation{Remove Parameter}{A parameter is no longer used by the method
676 %\explanation{Parameterize Method}{Several methods do similar things but with
677 %different values contained in the method.}{Create one method that uses a
678 %parameter for the different values.}
680 \explanation{Preserve Whole Object}{You are getting several values from an
681 object and passing these values as parameters in a method call.}{Send the whole
684 \explanation{Remove Setting Method}{A field should be set at creation time and
685 never altered.}{Remove any setting method for that field.}
687 \explanation{Hide Method}{A method is not used by any other class.}{Make the
690 \explanation{Replace Constructor with Factory Method}{You want to do more than
691 simple construction when you create an object}{Replace the constructor with a
694 % Dealing with Generalization
695 \explanation{Pull Up Field}{Two subclasses have the same field.}{Move the field
698 \explanation{Pull Up Method}{You have methods with identical results on
699 subclasses.}{Move them to the superclass.}
701 \explanation{Push Down Method}{Behavior on a superclass is relevant only for
702 some of its subclasses.}{Move it to those subclasses.}
704 \explanation{Push Down Field}{A field is used only by some subclasses.}{Move the
705 field to those subclasses}
707 \explanation{Extract Interface}{Several clients use the same subset of a class's
708 interface, or two classes have part of their interfaces in common.}{Extract the
709 subset into an interface.}
711 \explanation{Replace Inheritance with Delegation}{A subclass uses only part of a
712 superclasses interface or does not want to inherit data.}{Create a field for the
713 superclass, adjust methods to delegate to the superclass, and remove the
716 \explanation{Replace Delegation with Inheritance}{You're using delegation and
717 are often writing many simple delegations for the entire interface}{Make the
718 delegating class a subclass of the delegate.}
720 \subsubsection{Composite refactorings}
723 % \explanation{Replace Method with Method Object}{}{}
725 % Moving Features Between Objects
726 \explanation{Extract Class}{You have one class doing work that should be done by
727 two}{Create a new class and move the relevant fields and methods from the old
728 class into the new class.}
730 \explanation{Inline Class}{A class isn't doing very much.}{Move all its features
731 into another class and delete it.}
733 \explanation{Hide Delegate}{A client is calling a delegate class of an
734 object.}{Create Methods on the server to hide the delegate.}
736 \explanation{Remove Middle Man}{A class is doing to much simple delegation.}{Get
737 the client to call the delegate directly.}
740 \explanation{Replace Data Value with Object}{You have a data item that needs
741 additional data or behavior.}{Turn the data item into an object.}
743 \explanation{Change Value to Reference}{You have a class with many equal
744 instances that you want to replace with a single object.}{Turn the object into a
747 \explanation{Encapsulate Collection}{A method returns a collection}{Make it
748 return a read-only view and provide add/remove methods.}
750 % \explanation{Replace Array with Object}{}{}
752 \explanation{Replace Subclass with Fields}{You have subclasses that vary only in
753 methods that return constant data.}{Change the methods to superclass fields and
754 eliminate the subclasses.}
756 % Simplifying Conditional Expressions
757 \explanation{Decompose Conditional}{You have a complicated conditional
758 (if-then-else) statement.}{Extract methods from the condition, then part, an
761 \explanation{Consolidate Conditional Expression}{You have a sequence of
762 conditional tests with the same result.}{Combine them into a single conditional
763 expression and extract it.}
765 \explanation{Replace Conditional with Polymorphism}{You have a conditional that
766 chooses different behavior depending on the type of an object.}{Move each leg
767 of the conditional to an overriding method in a subclass. Make the original
770 % Making Method Calls Simpler
771 \explanation{Replace Parameter with Method}{An object invokes a method, then
772 passes the result as a parameter for a method. The receiver can also invoke this
773 method.}{Remove the parameter and let the receiver invoke the method.}
775 \explanation{Introduce Parameter Object}{You have a group of parameters that
776 naturally go together.}{Replace them with an object.}
778 % Dealing with Generalization
779 \explanation{Extract Subclass}{A class has features that are used only in some
780 instances.}{Create a subclass for that subset of features.}
782 \explanation{Extract Superclass}{You have two classes with similar
783 features.}{Create a superclass and move the common features to the
786 \explanation{Collapse Hierarchy}{A superclass and subclass are not very
787 different.}{Merge them together.}
789 \explanation{Form Template Method}{You have two methods in subclasses that
790 perform similar steps in the same order, yet the steps are different.}{Get the
791 steps into methods with the same signature, so that the original methods become
792 the same. Then you can pull them up.}
795 \subsection{Functional refactorings}
797 \explanation{Substitute Algorithm}{You want to replace an algorithm with one
798 that is clearer.}{Replace the body of the method with the new algorithm.}
802 \section{The impact on software quality}
804 \subsection{What is software quality?}
805 The term \emph{software quality} has many meanings. It all depends on the
806 context we put it in. If we look at it with the eyes of a software developer, it
807 usually means that the software is easily maintainable and testable, or in other
808 words, that it is \emph{well designed}. This often correlates with the
809 management scale, where \emph{keeping the schedule} and \emph{customer
810 satisfaction} is at the center. From the customers point of view, in addition to
811 good usability, \emph{performance} and \emph{lack of bugs} is always
812 appreciated, measurements that are also shared by the software developer. (In
813 addition, such things as good documentation could be measured, but this is out
814 of the scope of this document.)
816 \subsection{The impact on performance}
818 Refactoring certainly will make software go more slowly\footnote{With todays
819 compiler optimization techniques and performance tuning of e.g. the Java
820 virtual machine, the penalties of object creation and method calls are
821 debatable.}, but it also makes the software more amenable to performance
822 tuning.~\cite[p.~69]{refactoring}
825 \noindent There is a common belief that refactoring compromises performance, due
826 to increased degree of indirection and that polymorphism is slower than
829 In a survey, Demeyer\citing{demeyer2002} disproves this view in the case of
830 polymorphism. He did an experiment on, what he calls, ``Transform Self Type
831 Checks'' where you introduce a new polymorphic method and a new class hierarchy
832 to get rid of a class' type checking of a ``type attribute``. He uses this kind
833 of transformation to represent other ways of replacing conditionals with
834 polymorphism as well. The experiment is performed on the C++ programming
835 language and with three different compilers and platforms. Demeyer concludes
836 that, with compiler optimization turned on, polymorphism beats middle to large
837 sized if-statements and does as well as case-statements. (In accordance with
838 his hypothesis, due to similarities between the way C++ handles polymorphism and
842 The interesting thing about performance is that if you analyze most programs,
843 you find that they waste most of their time in a small fraction of the
844 code.~\cite[p.~70]{refactoring}
847 \noindent So, although an increased amount of method calls could potentially
848 slow down programs, one should avoid premature optimization and sacrificing good
849 design, leaving the performance tuning until after profiling\footnote{For and
850 example of a Java profiler, check out VisualVM:
851 \url{http://visualvm.java.net/}} the software and having isolated the actual
854 \section{Composite refactorings}\label{compositeRefactorings}
855 \todo{motivation, examples, manual vs automated?, what about refactoring in a
856 very large code base?}
857 Generally, when thinking about refactoring, at the mechanical level, there are
858 essentially two kinds of refactorings. There are the \emph{primitive}
859 refactorings, and the \emph{composite} refactorings.
861 \definition{A \emph{primitive refactoring} is a refactoring that cannot be
862 expressed in terms of other refactorings.}
864 \noindent Examples are the \refactoring{Pull Up Field} and \refactoring{Pull Up
865 Method} refactorings\citing{refactoring}, that move members up in their class
868 \definition{A \emph{composite refactoring} is a refactoring that can be
869 expressed in terms of two or more other refactorings.}
871 \noindent An example of a composite refactoring is the \refactoring{Extract
872 Superclass} refactoring\citing{refactoring}. In its simplest form, it is composed
873 of the previously described primitive refactorings, in addition to the
874 \refactoring{Pull Up Constructor Body} refactoring\citing{refactoring}. It works
875 by creating an abstract superclass that the target class(es) inherits from, then
876 by applying \refactoring{Pull Up Field}, \refactoring{Pull Up Method} and
877 \refactoring{Pull Up Constructor Body} on the members that are to be members of
878 the new superclass. For an overview of the \refactoring{Extract Superclass}
879 refactoring, see \myref{fig:extractSuperclass}.
883 \includegraphics[angle=270,width=\linewidth]{extractSuperclassItalic.pdf}
884 \caption{The Extract Superclass refactoring}
885 \label{fig:extractSuperclass}
888 \section{Manual vs. automated refactorings}
889 Refactoring is something every programmer does, even if \heshe does not known
890 the term \emph{refactoring}. Every refinement of source code that does not alter
891 the program's behavior is a refactoring. For small refactorings, such as
892 \ExtractMethod, executing it manually is a manageable task, but is still prone
893 to errors. Getting it right the first time is not easy, considering the method
894 signature and all the other aspects of the refactoring that has to be in place.
896 Take for instance the renaming of classes, methods and fields. For complex
897 programs these refactorings are almost impossible to get right. Attacking them
898 with textual search and replace, or even regular expressions, will fall short on
899 these tasks. Then it is crucial to have proper tool support that can perform
900 them automatically. Tools that can parse source code and thus have semantic
901 knowledge about which occurrences of which names belong to what construct in the
902 program. For even trying to perform one of these complex task manually, one
903 would have to be very confident on the existing test suite \see{testing}.
905 \section{Correctness of refactorings}\label{correctness}
906 For automated refactorings to be truly useful, they must show a high degree of
907 behavior preservation. This last sentence might seem obvious, but there are
908 examples of refactorings in existing tools that break programs. I will now
909 present an example of an \ExtractMethod refactoring followed by a \MoveMethod
910 refactoring that breaks a program in both the \emph{Eclipse} and \emph{IntelliJ}
911 IDEs\footnote{The NetBeans IDE handles this particular situation without
912 altering the program's beavior, mainly because its Move Method refactoring
913 implementation is a bit flawed in other ways \see{toolSupport}.}. The
914 following piece of code shows the target for the composed refactoring:
916 \begin{minted}[linenos,samepage]{java}
918 public X x = new X();
927 \noindent The next piece of code shows the destination of the refactoring. Note
928 that the method \method{m(C c)} of class \type{C} assigns to the field \var{x}
929 of the argument \var{c} that has type \type{C}:
931 \begin{minted}[samepage]{java}
940 The refactoring sequence works by extracting line 5 and 6 from the original
941 class \type{C} into a method \method{f} with the statements from those lines as
942 its method body. The method is then moved to the class \type{X}. The result is
943 shown in the following two pieces of code:
945 \begin{minted}[linenos,samepage]{java}
947 public X x = new X();
955 \begin{minted}[linenos,samepage]{java}
968 After the refactoring, the method \method{f} of class \type{C} is calling the
969 method \method{f} of class \type{X}, and the program now behaves different than
970 before. (See line 5 of the version of class \type{C} after the refactoring.)
971 Before the refactoring, the methods \method{m} and \method{n} of class \type{X}
972 are called on different object instances (see line 5 and 6 of the original class
973 \type{C}). After, they are called on the same object, and the statement on line
974 3 of class \type{X} (the version after the refactoring) no longer have any
975 effect in our example.
977 The bug introduced in the previous example is of such a nature\footnote{Caused
978 by aliasing. See \url{https://en.wikipedia.org/wiki/Aliasing_(computing)}}
979 that it is very difficult to spot if the refactored code is not covered by
980 tests. It does not generate compilation errors, and will thus only result in
981 a runtime error or corrupted data, which might be hard to detect.
983 \section{Refactoring and the importance of testing}\label{testing}
985 If you want to refactor, the essential precondition is having solid
986 tests.\citing{refactoring}
989 When refactoring, there are roughly three classes of errors that can be made.
990 The first class of errors are the ones that make the code unable to compile.
991 These \emph{compile-time} errors are of the nicer kind. They flash up at the
992 moment they are made (at least when using an IDE), and are usually easy to fix.
993 The second class are the \emph{runtime} errors. Although they take a bit longer
994 to surface, they usually manifest after some time in an illegal argument
995 exception, null pointer exception or similar during the program execution.
996 These kind of errors are a bit harder to handle, but at least they will show,
997 eventually. Then there are the \emph{behavior-changing} errors. These errors are
998 of the worst kind. They do not show up during compilation and they do not turn
999 on a blinking red light during runtime either. The program can seem to work
1000 perfectly fine with them in play, but the business logic can be damaged in ways
1001 that will only show up over time.
1003 For discovering runtime errors and behavior changes when refactoring, it is
1004 essential to have good test coverage. Testing in this context means writing
1005 automated tests. Manual testing may have its uses, but when refactoring, it is
1006 automated unit testing that dominate. For discovering behavior changes it is
1007 especially important to have tests that cover potential problems, since these
1008 kind of errors does not reveal themselves.
1010 Unit testing is not a way to \emph{prove} that a program is correct, but it is a
1011 way to make you confindent that it \emph{probably} works as desired. In the
1012 context of test driven development (commonly known as TDD), the tests are even a
1013 way to define how the program is \emph{supposed} to work. It is then, by
1014 definition, working if the tests are passing.
1016 If the test coverage for a code base is perfect, then it should, theoretically,
1017 be risk-free to perform refactorings on it. This is why automated tests and
1018 refactoring are such a great match.
1020 \subsection{Testing the code from correctness section}
1021 The worst thing that can happen when refactoring is to introduce changes to the
1022 behavior of a program, as in the example on \myref{correctness}. This example
1023 may be trivial, but the essence is clear. The only problem with the example is
1024 that it is not clear how to create automated tests for it, without changing it
1027 Unit tests, as they are known from the different xUnit frameworks around, are
1028 only suitable to test the \emph{result} of isolated operations. They can not
1029 easily (if at all) observe the \emph{history} of a program.
1031 This problem is still open.
1036 Assuming a sequential (non-concurrent) program:
1038 \begin{minted}{java}
1039 tracematch (C c, X x) {
1041 call(* X.m(C)) && args(c) && cflow(within(C));
1043 call(* X.n()) && target(x) && cflow(within(C));
1045 set(C.x) && target(c) && !cflow(m);
1049 { assert x == c.x; }
1053 %\begin{minted}{java}
1054 %tracematch (X x1, X x2) {
1056 % call(* X.m(C)) && target(x1);
1058 % call(* X.n()) && target(x2);
1060 % set(C.x) && !cflow(m) && !cflow(n);
1064 % { assert x1 != x2; }
1069 \section{The project}
1070 The aim of this master project will be to investigate the relationship between a
1071 composite refactoring composed of the \ExtractMethod and \MoveMethod
1072 refactorings, and its impact on one or more software metrics.
1074 The composition of the \ExtractMethod and \MoveMethod refactorings springs
1075 naturally out of the need to move procedures closer to the data they manipulate.
1076 This composed refactoring is not well described in the literature, but it is
1077 implemented in at least one tool called
1078 \emph{CodeRush}\footnote{\url{https://help.devexpress.com/\#CodeRush/CustomDocument3519}},
1079 that is an extension for \emph{MS Visual
1080 Studio}\footnote{\url{http://www.visualstudio.com/}}. In CodeRush it is called
1081 \emph{Extract Method to
1082 Type}\footnote{\url{https://help.devexpress.com/\#CodeRush/CustomDocument6710}},
1083 but I choose to call it \ExtractAndMoveMethod, since I feel it better
1084 communicates which primitive refactorings it is composed of.
1086 For the metrics, I will at least measure the \emph{Coupling between object
1087 classes} (CBO) metric that is described by Chidamber and Kemerer in their
1088 article \emph{A Metrics Suite for Object Oriented
1089 Design}\citing{metricsSuite1994}.
1091 The project will then consist in implementing the \ExtractAndMoveMethod
1092 refactoring, as well as executing it over a larger code base. Then the effect of
1093 the change must be measured by calculating the chosen software metrics both
1094 before and after the execution. To be able to execute the refactoring
1095 automatically I have to make it analyze code to determine the best selections to
1096 extract into new methods.
1100 %\chapter{Planning the project}
1106 \chapter{The Project}
1108 \section{The problem statement}
1111 \section{Choosing the target language}
1112 Choosing which programming language the code that shall be manipulated shall be
1113 written in, is not a very difficult task. We choose to limit the possible
1114 languages to the object-oriented programming languages, since most of the
1115 terminology and literature regarding refactoring comes from the world of
1116 object-oriented programming. In addition, the language must have existing tool
1117 support for refactoring.
1119 The \emph{Java} programming language\footnote{\url{https://www.java.com/}} is
1120 the dominating language when it comes to example code in the literature of
1121 refactoring, and is thus a natural choice. Java is perhaps, currently the most
1122 influential programming language in the world, with its \emph{Java Virtual
1123 Machine} that runs on all of the most popular architectures and also supports
1124 dozens of other programming languages\footnote{They compile to java bytecode.},
1125 with \emph{Scala}, \emph{Clojure} and \emph{Groovy} as the most prominent ones.
1126 Java is currently the language that every other programming language is compared
1127 against. It is also the primary programming language for the author of this
1130 \section{Choosing the tools}
1131 When choosing a tool for manipulating Java, there are certain criterias that
1132 have to be met. First of all, the tool should have some existing refactoring
1133 support that this thesis can build upon. Secondly it should provide some kind of
1134 framework for parsing and analyzing Java source code. Third, it should itself be
1135 open source. This is both because of the need to be able to browse the code for
1136 the existing refactorings that is contained in the tool, and also because open
1137 source projects hold value in them selves. Another important aspect to consider
1138 is that open source projects of a certain size, usually has large communities of
1139 people connected to them, that are commited to answering questions regarding the
1140 use and misuse of the products, that to a large degree is made by the cummunity
1143 There is a certain class of tools that meet these criterias, namely the class of
1144 \emph{IDEs}\footnote{\emph{Integrated Development Environment}}. These are
1145 proagrams that is ment to support the whole production cycle of a cumputer
1146 program, and the most popular IDEs that support Java, generally have quite good
1147 refactoring support.
1149 The main contenders for this thesis is the \emph{Eclipse IDE}, with the
1150 \emph{Java development tools} (JDT), the \emph{IntelliJ IDEA Community Edition}
1151 and the \emph{NetBeans IDE} \see{toolSupport}. Eclipse and NetBeans are both
1152 free, open source and community driven, while the IntelliJ IDEA has an open
1153 sourced community edition that is free of charge, but also offer an
1154 \emph{Ultimate Edition} with an extended set of features, at additional cost.
1155 All three IDEs supports adding plugins to extend their functionality and tools
1156 that can be used to parse and analyze Java source code. But one of the IDEs
1157 stand out as a favorite, and that is the \emph{Eclipse IDE}. This is the most
1158 popular\citing{javaReport2011} among them and seems to be de facto standard IDE
1159 for Java development regardless of platform.
1161 \section{Organizing the project}
1162 All the parts of this master project is under version control with
1163 \emph{Git}\footnote{\url{http://git-scm.com/}}.
1165 The software written is organized as some Eclipse plugins. Writing a plugin is
1166 the natural way to utilize the API of Eclipse. This also makes it possible to
1167 provide a user interface to manually run operations on selections in program
1168 source code or whole projects/packages.
1170 When writing a plugin in Eclipse, one has access to resources such as the
1171 current workspace, the open editor and the current selection.
1173 \section{Continuous integration}
1174 The continuous integration server
1175 \emph{Jenkins}\footnote{\url{http://jenkins-ci.org/}} has been set up for the
1176 project\footnote{A work mostly done by the supervisor.}. It is used as a way to
1177 run tests and perform code coverage analysis.
1179 To be able to build the Eclipse plugins and run tests for them with Jenkins, the
1180 component assembly project
1181 \emph{Buckminster}\footnote{\url{http://www.eclipse.org/buckminster/}} is used,
1182 through its plugin for Jenkins. Buckminster provides for a way to specify the
1183 resources needed for building a project and where and how to find them.
1184 Buckminster also handles the setup of a target environment to run the tests in.
1185 All this is needed because the code to build depends on an Eclipse installation
1186 with various plugins.
1188 \subsection{Problems with AspectJ}
1189 The Buckminster build worked fine until introducing AspectJ into the project.
1190 When building projects using AspectJ, there are some additional steps that needs
1191 to be performed. First of all, the aspects themselves must be compiled. Then the
1192 aspects needs to be woven with the classes they affect. This demands a process
1193 that does multiple passes over the source code.
1195 When using AspectJ with Eclipse, the specialized compilation and the weaving can
1196 be handled by the \emph{AspectJ Development
1197 Tools}\footnote{\url{https://www.eclipse.org/ajdt/}}. This works all fine, but
1198 it complicates things when trying to build a project depending on Eclipse
1199 plugins outside of Eclipse. There is supposed to be a way to specify a compiler
1200 adapter for javac, together with the file extensions for the file types it shall
1201 operate. The AspectJ compiler adapter is called
1202 \typewithref{org.aspectj.tools.ant.taskdefs}{Ajc11CompilerAdapter}, and it works
1203 with files that has the extensions \code{*.java} and \code{*.aj}. I tried to
1204 setup this in the build properties file for the project containing the aspects,
1205 but to no avail. The project containing the aspects does not seem to be built at
1206 all, and the projects that depends on it complains that they cannot find certain
1209 I then managed to write an \emph{Ant}\footnote{\url{https://ant.apache.org/}}
1210 build file that utilizes the AspectJ compiler adapter, for the
1211 \code{no.uio.ifi.refaktor} plugin. The problem was then that it could no longer
1212 take advantage of the environment set up by Buckminster. The solution to this
1213 particular problem was of a ``hacky'' nature. It involves exporting the plugin
1214 dependencies for the project to an Ant build file, and copy the exported path
1215 into the existing build script. But then the Ant script needs to know where the
1216 local Eclipse installation is located. This is no problem when building on a
1217 local machine, but to utilize the setup done by Buckminster is a problem still
1218 unsolved. To get the classpath for the build setup correctly, and here comes the
1219 most ``hacky'' part of the solution, the Ant script has a target for copying the
1220 classpath elements into a directory relative to the project directory and
1221 checking it into Git. When no \code{ECLIPSE\_HOME} property is set while running
1222 Ant, the script uses the copied plugins instead of the ones provided by the
1223 Eclipse installation when building the project. This obviously creates some
1224 problems with maintaining the list of dependencies in the Ant file, as well as
1225 remembering to copy the plugins every time the list of dependencies change.
1227 The Ant script described above is run by Jenkins before the Buckminster setup
1228 and build. When setup like this, the Buckminster build succeeds for the projects
1229 not using AspectJ, and the tests are run as normal. This is all good, but it
1230 feels a little scary, since the reason for Buckminster not working with AspectJ
1233 The problems with building with AspectJ on the Jenkins server lasted for a
1234 while, before they were solved. This is reflected in the ``Test Result Trend''
1235 and ``Code Coverage Trend'' reported by Jenkins.
1238 \chapter{Refactorings in Eclipse JDT: Design, Shortcomings and Wishful
1239 Thinking}\label{ch:jdt_refactorings}
1241 This chapter will deal with some of the design behind refactoring support in
1242 Eclipse, and the JDT in specific. After which it will follow a section about
1243 shortcomings of the refactoring API in terms of composition of refactorings. The
1244 chapter will be concluded with a section telling some of the ways the
1245 implementation of refactorings in the JDT could have worked to facilitate
1246 composition of refactorings.
1249 The refactoring world of Eclipse can in general be separated into two parts: The
1250 language independent part and the part written for a specific programming
1251 language -- the language that is the target of the supported refactorings.
1252 \todo{What about the language specific part?}
1254 \subsection{The Language Toolkit}
1255 The Language Toolkit\footnote{The content of this section is a mixture of
1256 written material from
1257 \url{https://www.eclipse.org/articles/Article-LTK/ltk.html} and
1258 \url{http://www.eclipse.org/articles/article.php?file=Article-Unleashing-the-Power-of-Refactoring/index.html},
1259 the LTK source code and my own memory.}, or LTK for short, is the framework that
1260 is used to implement refactorings in Eclipse. It is language independent and
1261 provides the abstractions of a refactoring and the change it generates, in the
1262 form of the classes \typewithref{org.eclipse.ltk.core.refactoring}{Refactoring}
1263 and \typewithref{org.eclipse.ltk.core.refactoring}{Change}.
1265 There are also parts of the LTK that is concerned with user interaction, but
1266 they will not be discussed here, since they are of little value to us and our
1267 use of the framework. We are primarily interested in the parts that can be
1270 \subsubsection{The Refactoring Class}
1271 The abstract class \type{Refactoring} is the core of the LTK framework. Every
1272 refactoring that is going to be supported by the LTK have to end up creating an
1273 instance of one of its subclasses. The main responsibilities of subclasses of
1274 \type{Refactoring} is to implement template methods for condition checking
1275 (\methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{checkInitialConditions}
1277 \methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{checkFinalConditions}),
1279 \methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{createChange}
1280 method that creates and returns an instance of the \type{Change} class.
1282 If the refactoring shall support that others participate in it when it is
1283 executed, the refactoring has to be a processor-based
1284 refactoring\typeref{org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring}.
1285 It then delegates to its given
1286 \typewithref{org.eclipse.ltk.core.refactoring.participants}{RefactoringProcessor}
1287 for condition checking and change creation. Participating in a refactoring can
1288 be useful in cases where the changes done to programming source code affects
1289 other related resources in the workspace. This can be names or paths in
1290 configuration files, or maybe one would like to perform additional logging of
1291 changes done in the workspace.
1293 \subsubsection{The Change Class}
1294 This class is the base class for objects that is responsible for performing the
1295 actual workspace transformations in a refactoring. The main responsibilities for
1296 its subclasses is to implement the
1297 \methodwithref{org.eclipse.ltk.core.refactoring.Change}{perform} and
1298 \methodwithref{org.eclipse.ltk.core.refactoring.Change}{isValid} methods. The
1299 \method{isValid} method verifies that the change object is valid and thus can be
1300 executed by calling its \method{perform} method. The \method{perform} method
1301 performs the desired change and returns an undo change that can be executed to
1302 reverse the effect of the transformation done by its originating change object.
1304 \subsubsection{Executing a Refactoring}\label{executing_refactoring}
1305 The life cycle of a refactoring generally follows two steps after creation:
1306 condition checking and change creation. By letting the refactoring object be
1308 \typewithref{org.eclipse.ltk.core.refactoring}{CheckConditionsOperation} that
1309 in turn is handled by a
1310 \typewithref{org.eclipse.ltk.core.refactoring}{CreateChangeOperation}, it is
1311 assured that the change creation process is managed in a proper manner.
1313 The actual execution of a change object has to follow a detailed life cycle.
1314 This life cycle is honored if the \type{CreateChangeOperation} is handled by a
1315 \typewithref{org.eclipse.ltk.core.refactoring}{PerformChangeOperation}. If also
1316 an undo manager\typeref{org.eclipse.ltk.core.refactoring.IUndoManager} is set
1317 for the \type{PerformChangeOperation}, the undo change is added into the undo
1320 \section{Shortcomings}
1321 This section is introduced naturally with a conclusion: The JDT refactoring
1322 implementation does not facilitate composition of refactorings.
1323 \todo{refine}This section will try to explain why, and also identify other
1324 shortcomings of both the usability and the readability of the JDT refactoring
1327 I will begin at the end and work my way toward the composition part of this
1330 \subsection{Absence of Generics in Eclipse Source Code}
1331 This section is not only concerning the JDT refactoring API, but also large
1332 quantities of the Eclipse source code. The code shows a striking absence of the
1333 Java language feature of generics. It is hard to read a class' interface when
1334 methods return objects or takes parameters of raw types such as \type{List} or
1335 \type{Map}. This sometimes results in having to read a lot of source code to
1336 understand what is going on, instead of relying on the available interfaces. In
1337 addition, it results in a lot of ugly code, making the use of typecasting more
1338 of a rule than an exception.
1340 \subsection{Composite Refactorings Will Not Appear as Atomic Actions}
1342 \subsubsection{Missing Flexibility from JDT Refactorings}
1343 The JDT refactorings are not made with composition of refactorings in mind. When
1344 a JDT refactoring is executed, it assumes that all conditions for it to be
1345 applied successfully can be found by reading source files that have been
1346 persisted to disk. They can only operate on the actual source material, and not
1347 (in-memory) copies thereof. This constitutes a major disadvantage when trying to
1348 compose refactorings, since if an exception occurs in the middle of a sequence
1349 of refactorings, it can leave the project in a state where the composite
1350 refactoring was only partially executed. It makes it hard to discard the changes
1351 done without monitoring and consulting the undo manager, an approach that is not
1354 \subsubsection{Broken Undo History}
1355 When designing a composed refactoring that is to be performed as a sequence of
1356 refactorings, you would like it to appear as a single change to the workspace.
1357 This implies that you would also like to be able to undo all the changes done by
1358 the refactoring in a single step. This is not the way it appears when a sequence
1359 of JDT refactorings is executed. It leaves the undo history filled up with
1360 individual undo actions corresponding to every single JDT refactoring in the
1361 sequence. This problem is not trivial to handle in Eclipse
1362 \see{hacking_undo_history}.
1364 \section{Wishful Thinking}
1367 \chapter{Composite Refactorings in Eclipse}
1369 \section{A Simple Ad Hoc Model}
1370 As pointed out in \myref{ch:jdt_refactorings}, the Eclipse JDT refactoring model
1371 is not very well suited for making composite refactorings. Therefore a simple
1372 model using changer objects (of type \type{RefaktorChanger}) is used as an
1373 abstraction layer on top of the existing Eclipse refactorings, instead of
1374 extending the \typewithref{org.eclipse.ltk.core.refactoring}{Refactoring} class.
1376 The use of an additional abstraction layer is a deliberate choice. It is due to
1377 the problem of creating a composite
1378 \typewithref{org.eclipse.ltk.core.refactoring}{Change} that can handle text
1379 changes that interfere with each other. Thus, a \type{RefaktorChanger} may, or
1380 may not, take advantage of one or more existing refactorings, but it is always
1381 intended to make a change to the workspace.
1383 \subsection{A typical \type{RefaktorChanger}}
1384 The typical refaktor changer class has two responsibilities, checking
1385 preconditions and executing the requested changes. This is not too different
1386 from the responsibilities of an LTK refactoring, with the distinction that a
1387 refaktor changer also executes the change, while an LTK refactoring is only
1388 responsible for creating the object that can later be used to do the job.
1390 Checking of preconditions is typically done by an
1391 \typewithref{no.uio.ifi.refaktor.analyze.analyzers}{Analyzer}. If the
1392 preconditions validate, the upcoming changes are executed by an
1393 \typewithref{no.uio.ifi.refaktor.change.executors}{Executor}.
1395 \section{The Extract and Move Method Refactoring}
1396 %The Extract and Move Method Refactoring is implemented mainly using these
1399 % \item \type{ExtractAndMoveMethodChanger}
1400 % \item \type{ExtractAndMoveMethodPrefixesExtractor}
1401 % \item \type{Prefix}
1402 % \item \type{PrefixSet}
1405 \subsection{The Building Blocks}
1406 This is a composite refactoring, and hence is built up using several primitive
1407 refactorings. These basic building blocks are, as its name implies, the
1408 \ExtractMethod refactoring\citing{refactoring} and the \MoveMethod
1409 refactoring\citing{refactoring}. In Eclipse, the implementations of these
1410 refactorings are found in the classes
1411 \typewithref{org.eclipse.jdt.internal.corext.refactoring.code}{ExtractMethodRefactoring}
1413 \typewithref{org.eclipse.jdt.internal.corext.refactoring.structure}{MoveInstanceMethodProcessor},
1414 where the last class is designed to be used together with the processor-based
1415 \typewithref{org.eclipse.ltk.core.refactoring.participants}{MoveRefactoring}.
1417 \subsubsection{The ExtractMethodRefactoring Class}
1418 This class is quite simple in its use. The only parameters it requires for
1419 construction is a compilation
1420 unit\typeref{org.eclipse.jdt.core.ICompilationUnit}, the offset into the source
1421 code where the extraction shall start, and the length of the source to be
1422 extracted. Then you have to set the method name for the new method together with
1423 its visibility and some not so interesting parameters.
1425 \subsubsection{The MoveInstanceMethodProcessor Class}
1426 For the Move Method, the processor requires a little more advanced input than
1427 the class for the Extract Method. For construction it requires a method
1428 handle\typeref{org.eclipse.jdt.core.IMethod} for the method that is to be moved.
1429 Then the target for the move have to be supplied as the variable binding from a
1430 chosen variable declaration. In addition to this, one have to set some
1431 parameters regarding setters/getters, as well as delegation.
1433 To make a working refactoring from the processor, one have to create a
1434 \type{MoveRefactoring} with it.
1436 \subsection{The ExtractAndMoveMethodChanger}
1438 The \typewithref{no.uio.ifi.refaktor.changers}{ExtractAndMoveMethodChanger}
1439 class is a subclass of the class
1440 \typewithref{no.uio.ifi.refaktor.changers}{RefaktorChanger}. It is responsible
1441 for analyzing and finding the best target for, and also executing, a composition
1442 of the Extract Method and Move Method refactorings. This particular changer is
1443 the one of my changers that is closest to being a true LTK refactoring. It can
1444 be reworked to be one if the problems with overlapping changes are resolved. The
1445 changer requires a text selection and the name of the new method, or else a
1446 method name will be generated. The selection has to be of the type
1447 \typewithref{no.uio.ifi.refaktor.utils}{CompilationUnitTextSelection}. This
1448 class is a custom extension to
1449 \typewithref{org.eclipse.jface.text}{TextSelection}, that in addition to the
1450 basic offset, length and similar methods, also carry an instance of the
1451 underlying compilation unit handle for the selection.
1454 \type{ExtractAndMoveMethodAnalyzer}}\label{extractAndMoveMethodAnalyzer}
1455 The analysis and precondition checking is done by the
1456 \typewithref{no.uio.ifi.refaktor.analyze.analyzers}{ExtractAnd\-MoveMethodAnalyzer}.
1457 First is check whether the selection is a valid selection or not, with respect
1458 to statement boundaries and that it actually contains any selections. Then it
1459 checks the legality of both extracting the selection and also moving it to
1460 another class. This checking of is performed by a range of checkers
1461 \see{checkers}. If the selection is approved as legal, it is analyzed to find
1462 the presumably best target to move the extracted method to.
1464 For finding the best suitable target the analyzer is using a
1465 \typewithref{no.uio.ifi.refaktor.analyze.collectors}{PrefixesCollector} that
1466 collects all the possible candidate targets for the refactoring. All the
1467 non-candidates is found by an
1468 \typewithref{no.uio.ifi.refaktor.analyze.collectors}{UnfixesCollector} that
1469 collects all the targets that will give some kind of error if used. (For
1470 details about the property collectors, se \myref{propertyCollectors}.) All
1471 prefixes (and unfixes) are represented by a
1472 \typewithref{no.uio.ifi.refaktor.extractors}{Prefix}, and they are collected
1473 into sets of prefixes. The safe prefixes is found by subtracting from the set of
1474 candidate prefixes the prefixes that is enclosing any of the unfixes. A prefix
1475 is enclosing an unfix if the unfix is in the set of its sub-prefixes. As an
1476 example, \texttt{``a.b''} is enclosing \texttt{``a''}, as is \texttt{``a''}. The
1477 safe prefixes is unified in a \type{PrefixSet}. If a prefix has only one
1478 occurrence, and is a simple expression, it is considered unsuitable as a move
1479 target. This occurs in statements such as \texttt{``a.foo()''}. For such
1480 statements it bares no meaning to extract and move them. It only generates an
1481 extra method and the calling of it.
1483 The most suitable target for the refactoring is found by finding the prefix with
1484 the most occurrences. If two prefixes have the same occurrence count, but they
1485 differ in length, the longest of them is chosen.
1487 \todoin{Clean up sections/subsections.}
1490 \type{ExtractAndMoveMethodExecutor}}\label{extractAndMoveMethodExecutor}
1491 If the analysis finds a possible target for the composite refactoring, it is
1493 \typewithref{no.uio.ifi.refaktor.change.executors}{ExtractAndMoveMethodExecutor}.
1494 It is composed of the two executors known as
1495 \typewithref{no.uio.ifi.refaktor.change.executors}{ExtractMethodRefactoringExecutor}
1497 \typewithref{no.uio.ifi.refaktor.change.executors}{MoveMethodRefactoringExecutor}.
1498 The \type{ExtractAndMoveMethodExecutor} is responsible for gluing the two
1499 together by feeding the \type{MoveMethod\-RefactoringExecutor} with the
1500 resources needed after executing the extract method refactoring
1501 \see{postExtractExecution}.
1503 \subsubsection{The \type{ExtractMethodRefactoringExecutor}}
1504 This executor is responsible for creating and executing an instance of the
1505 \type{ExtractMethodRefactoring} class. It is also responsible for collecting
1506 some post execution resources that can be used to find the method handle for the
1507 extracted method, as well as information about its parameters, including the
1508 variable they originated from.
1510 \subsubsection{The \type{MoveMethodRefactoringExecutor}}
1511 This executor is responsible for creating and executing an instance of the
1512 \type{MoveRefactoring}. The move refactoring is a processor-based refactoring,
1513 and for the Move Method refactoring it is the \type{MoveInstanceMethodProcessor}
1516 The handle for the method to be moved is found on the basis of the information
1517 gathered after the execution of the Extract Method refactoring. The only
1518 information the \type{ExtractMethodRefactoring} is sharing after its execution,
1519 regarding find the method handle, is the textual representation of the new
1520 method signature. Therefore it must be parsed, the strings for types of the
1521 parameters must be found and translated to a form that can be used to look up
1522 the method handle from its type handle. They have to be on the unresolved
1523 form.\todo{Elaborate?} The name for the type is found from the original
1524 selection, since an extracted method must end up in the same type as the
1527 When analyzing a selection prior to performing the Extract Method refactoring, a
1528 target is chosen. It has to be a variable binding, so it is either a field or a
1529 local variable/parameter. If the target is a field, it can be used with the
1530 \type{MoveInstanceMethodProcessor} as it is, since the extracted method still is
1531 in its scope. But if the target is local to the originating method, the target
1532 that is to be used for the processor must be among its parameters. Thus the
1533 target must be found among the extracted method's parameters. This is done by
1534 finding the parameter information object that corresponds to the parameter that
1535 was declared on basis of the original target's variable when the method was
1536 extracted. (The extracted method must take one such parameter for each local
1537 variable that is declared outside the selection that is extracted.) To match the
1538 original target with the correct parameter information object, the key for the
1539 information object is compared to the key from the original target's binding.
1540 The source code must then be parsed to find the method declaration for the
1541 extracted method. The new target must be found by searching through the
1542 parameters of the declaration and choose the one that has the same type as the
1543 old binding from the parameter information object, as well as the same name that
1544 is provided by the parameter information object.
1548 SearchBasedExtractAndMoveMethodChanger}\label{searchBasedExtractAndMoveMethodChanger}
1550 \typewithref{no.uio.ifi.refaktor.change.changers}{SearchBasedExtractAndMoveMethodChanger}
1551 is a changer whose purpose is to automatically analyze a method, and execute the
1552 \ExtractAndMoveMethod refactoring on it if it is a suitable candidate for the
1555 First, the \typewithref{no.uio.ifi.refaktor.analyze.analyzers}{SearchBasedExtractAndMoveMethodAnalyzer} is used
1556 to analyze the method. If the method is found to be a candidate, the result from
1557 the analysis is fed to the \type{ExtractAndMoveMethodExecutor}, whose job is to
1558 execute the refactoring \see{extractAndMoveMethodExecutor}.
1560 \subsubsection{The SearchBasedExtractAndMoveMethodAnalyzer}
1561 This analyzer is responsible for analyzing all the possible text selections of a
1562 method and then choose the best result out of the analysis results that is, by
1563 the analyzer, considered to be the potential candidates for the Extract and Move
1566 Before the analyzer is able to work with the text selections of a method, it
1567 needs to generate them. To do this, it parses the method to obtain a
1568 \type{MethodDeclaration} for it \see{astEclipse}. Then there is a statement
1569 lists creator that creates statements lists of the different groups of
1570 statements in the body of the method declaration. A text selections generator
1571 generates text selections of all the statement lists for the analyzer to work
1574 \paragraph{The statement lists creator}
1575 is responsible for generating lists of statements for all the possible levels of
1576 statements in the method. The statement lists creator is implemented as an AST
1577 visitor \see{astVisitor}. It generates lists of statements by visiting all the
1578 blocks in the method declaration and stores their statements in a collection of
1579 statement lists. In addition, it visits all of the other statements that can
1580 have a statement as a child, such as the different control structures and the
1583 The switch statement is the only kind of statement that is not straight forward
1584 to obtain the child statements from. It stores all of its children in a flat
1585 list. Its switch case statements are included in this list. This means that
1586 there are potential statement lists between all of these case statements. The
1587 list of statements from a switch statement is therefore traversed, and the
1588 statements between the case statements are grouped as separate lists.
1590 There is an example of how the statement lists creator would generate lists for
1591 a simple method in \myref{lst:statementListsExample}.
1594 \def\charwidth{5.7pt}
1595 \def\indent{4*\charwidth}
1596 \def\lineheight{\baselineskip}
1597 \def\mintedtop{\lineheight}
1599 \begin{tikzpicture}[overlay, yscale=-1]
1600 \tikzstyle{overlaybox}=[fill=lightgray,opacity=0.2]
1601 \draw[overlaybox] (0,\mintedtop+\lineheight) rectangle
1602 +(22*\charwidth,10*\lineheight);
1603 \draw[overlaybox] (\indent,\mintedtop+2*\lineheight) rectangle
1604 +(13*\charwidth,\lineheight);
1605 \draw[overlaybox] (2*\indent,\mintedtop+6*\lineheight) rectangle
1606 +(13*\charwidth,2*\lineheight);
1607 \draw[overlaybox] (2*\indent,\mintedtop+9*\lineheight) rectangle
1608 +(13*\charwidth,\lineheight);
1610 \begin{minted}{java}
1624 \caption{Example of how the statement lists creator would group a simple method
1625 into lists of statements. Each highlighted rectangle represents a list.}
1626 \label{lst:statementListsExample}
1629 \paragraph{The text selections generator} generates text selections for each
1630 list of statements from the statement lists creator. Conceptually, the generator
1631 generates a text selection for every possible ordered \todo{make clearer}
1632 combination of statements in a list. For a list of statements, the boundary
1633 statements span out a text selection. This means that there are many different
1634 lists that could span out the same selection.
1636 In practice, the text selections are calculated by only one traversal of the
1637 statement list. There is a set of generated text selections. For each statement,
1638 there is created a temporary set of selections, in addition to a text selection
1639 based on the offset and length of the statement. This text selection is added to
1640 the temporary set. Then the new selection is added with every selection from the
1641 set of generated text selections. These new selections are added to the
1642 temporary set. Then the temporary set of selections is added to the set of
1643 generated text selections. The result of adding two text selections is a new
1644 text selection spanned out by the two addends.
1646 \paragraph{Finding the candidate} for the refactoring is done by analyzing all
1647 the generated text selection with the \type{ExtractAndMoveMethodAnalyzer}
1648 \see{extractAndMoveMethodAnalyzer}. If the analyzer generates a useful result,
1649 an \type{ExtractAndMoveMethodCandidate} is created from it, that is kept in a
1650 list of potential candidates. If no candidates are found, the
1651 \type{NoTargetFoundException} is thrown.
1653 Since only one of the candidates can be chosen, the analyzer must sort out which
1654 candidate to choose. The sorting is done by the static \method{sort} method of
1655 \type{Collections}. The comparison in this sorting is done by an
1656 \type{ExtractAndMoveMethodCandidateComparator}.
1657 \todoin{Write about the
1658 ExtractAndMoveMethodCandidateComparator/FavorNoUnfixesCandidateComparator}
1660 \paragraph{The complexity} of how many text selections that needs to be analyzed
1661 for a total of $n$ statements is bounded by $O(n^2)$.
1664 The number of text selections that need to be analyzed for each list of
1665 statements of length $n$, is exactly
1668 \sum_{i=1}^{n} i = \frac{n(n+1)}{2}
1669 \label{eq:complexityStatementList}
1671 \label{thm:numberOfTextSelection}
1675 For $n=1$ this is trivial: $\frac{1(1+1)}{2} = \frac{2}{2} = 1$. One statement
1676 equals one selection.
1678 For $n=2$, you get one text selection for the first statement. For the second,
1679 you get one selection for the statement itself, and one selection for the two
1680 of them combined. This equals three selections. $\frac{2(2+1)}{2} =
1683 For $n=3$, you get 3 selections for the two first statements, as in the case
1684 where $n=2$. In addition you get one selection for the third statement itself,
1685 and two more statements for the combinations of it with the two previous
1686 statements. This equals six selections. $\frac{3(3+1)}{2} = \frac{12}{2} = 6$.
1688 Assume that for $n=k$ there exists $\frac{k(k+1)}{2}$ text selections. Then we
1689 want to add selections for another statement, following the previous $k$
1690 statements. So, for $n=k+1$, we get one additional selection for the statement
1691 itself. Then we get one selection for each pair of the new selection and the
1692 previous $k$ statements. So the total number of selections will be the number
1693 of already generated selections, plus $k$ for every pair, plus one for the
1694 statement itself: $\frac{k(k+1)}{2} + k +
1695 1 = \frac{k(k+1)+2k+2}{2} = \frac{k(k+1)+2(k+1)}{2} = \frac{(k+1)(k+2)}{2} =
1696 \frac{(k+1)((k+1)+1)}{2} = \sum_{i=1}^{k+1} i$
1700 The number of text selections for a body of statements is maximized if all the
1701 statements are at the same level.
1702 \label{thm:textSelectionsMaximized}
1706 Assume we have a body of, in total, $k$ stamements. Let
1707 $l,\cdots,m,(k-l-\cdots-m)$ be the lengths of the lists of statements in the
1708 body, with $l+\cdots+m<k \Rightarrow l,\cdots,m<k$.
1710 Then, the number of text selections that are generated for the $k$ statements
1716 \frac{(k-l-\cdots-m)((k-l-\cdots-m)+ 1)}{2} + \frac{l(l+1)}{2} + \cdots +
1717 \frac{m(m+1)}{2} = \\
1718 \frac{k^2 - 2kl - \cdots - 2km + l^2 + \cdots + m^2 + k - l - \cdots - m}{2}
1719 + \frac{l^2+l}{2} + \cdots + \frac{m^2+m}{2} = \\
1720 \frac{k^2 + k + 2l^2 - 2kl + \cdots + 2m^2 - 2km}{2}
1724 It then remains to show that this inequality holds:
1727 \frac{k^2 + k + 2l^2 - 2kl + \cdots + 2m^2 - 2km}{2} < \frac{k(k+1)}{2} =
1731 By multiplication by $2$ on both sides, and by removing the equal parts, we get
1734 2l^2 - 2kl + \cdots + 2m^2 - 2km < 0
1737 Since $l,\cdots,m<k$, we have that $\forall i \in \{l,\cdots,m\} : 2ki > 2i^2$,
1738 so all the pairs of parts on the form $2i^2-2ki$ are negative. In sum, the
1743 Therefore, the complexity for the number of selections that needs to be analyzed
1744 for a body of $n$ statements is $O\bigl(\frac{n(n+1)}{2}\bigr) = O(n^2)$.
1747 \subsection{Finding the IMethod}\label{postExtractExecution}
1748 \todoin{Rename section. Write??}
1751 \subsection{The Prefix Class}
1752 This class exists mainly for holding data about a prefix, such as the expression
1753 that the prefix represents and the occurrence count of the prefix within a
1754 selection. In addition to this, it has some functionality such as calculating
1755 its sub-prefixes and intersecting it with another prefix. The definition of the
1756 intersection between two prefixes is a prefix representing the longest common
1757 expression between the two.
1759 \subsection{The PrefixSet Class}
1760 A prefix set holds elements of type \type{Prefix}. It is implemented with the
1761 help of a \typewithref{java.util}{HashMap} and contains some typical set
1762 operations, but it does not implement the \typewithref{java.util}{Set}
1763 interface, since the prefix set does not need all of the functionality a
1764 \type{Set} requires to be implemented. In addition It needs some other
1765 functionality not found in the \type{Set} interface. So due to the relatively
1766 limited use of prefix sets, and that it almost always needs to be referenced as
1767 such, and not a \type{Set<Prefix>}, it remains as an ad hoc solution to a
1770 There are two ways adding prefixes to a \type{PrefixSet}. The first is through
1771 its \method{add} method. This works like one would expect from a set. It adds
1772 the prefix to the set if it does not already contain the prefix. The other way
1773 is to \emph{register} the prefix with the set. When registering a prefix, if the
1774 set does not contain the prefix, it is just added. If the set contains the
1775 prefix, its count gets incremented. This is how the occurrence count is handled.
1777 The prefix set also computes the set of prefixes that is not enclosing any
1778 prefixes of another set. This is kind of a set difference operation only for
1781 \subsection{Hacking the Refactoring Undo
1782 History}\label{hacking_undo_history}
1783 \todoin{Where to put this section?}
1785 As an attempt to make multiple subsequent changes to the workspace appear as a
1786 single action (i.e. make the undo changes appear as such), I tried to alter
1787 the undo changes\typeref{org.eclipse.ltk.core.refactoring.Change} in the history
1788 of the refactorings.
1790 My first impulse was to remove the, in this case, last two undo changes from the
1791 undo manager\typeref{org.eclipse.ltk.core.refactoring.IUndoManager} for the
1792 Eclipse refactorings, and then add them to a composite
1793 change\typeref{org.eclipse.ltk.core.refactoring.CompositeChange} that could be
1794 added back to the manager. The interface of the undo manager does not offer a
1795 way to remove/pop the last added undo change, so a possible solution could be to
1796 decorate\citing{designPatterns} the undo manager, to intercept and collect the
1797 undo changes before delegating to the \method{addUndo}
1798 method\methodref{org.eclipse.ltk.core.refactoring.IUndoManager}{addUndo} of the
1799 manager. Instead of giving it the intended undo change, a null change could be
1800 given to prevent it from making any changes if run. Then one could let the
1801 collected undo changes form a composite change to be added to the manager.
1803 There is a technical challenge with this approach, and it relates to the undo
1804 manager, and the concrete implementation
1805 UndoManager2\typeref{org.eclipse.ltk.internal.core.refactoring.UndoManager2}.
1806 This implementation is designed in a way that it is not possible to just add an
1807 undo change, you have to do it in the context of an active
1808 operation\typeref{org.eclipse.core.commands.operations.TriggeredOperations}.
1809 One could imagine that it might be possible to trick the undo manager into
1810 believing that you are doing a real change, by executing a refactoring that is
1811 returning a kind of null change that is returning our composite change of undo
1812 refactorings when it is performed.
1814 Apart from the technical problems with this solution, there is a functional
1815 problem: If it all had worked out as planned, this would leave the undo history
1816 in a dirty state, with multiple empty undo operations corresponding to each of
1817 the sequentially executed refactoring operations, followed by a composite undo
1818 change corresponding to an empty change of the workspace for rounding of our
1819 composite refactoring. The solution to this particular problem could be to
1820 intercept the registration of the intermediate changes in the undo manager, and
1821 only register the last empty change.
1823 Unfortunately, not everything works as desired with this solution. The grouping
1824 of the undo changes into the composite change does not make the undo operation
1825 appear as an atomic operation. The undo operation is still split up into
1826 separate undo actions, corresponding to the change done by its originating
1827 refactoring. And in addition, the undo actions has to be performed separate in
1828 all the editors involved. This makes it no solution at all, but a step toward
1831 There might be a solution to this problem, but it remains to be found. The
1832 design of the refactoring undo management is partly to be blamed for this, as it
1833 it is to complex to be easily manipulated.
1838 \chapter{Analyzing Source Code in Eclipse}
1840 \section{The Java model}\label{javaModel}
1841 The Java model of Eclipse is its internal representation of a Java project. It
1842 is light-weight, and has only limited possibilities for manipulating source
1843 code. It is typically used as a basis for the Package Explorer in Eclipse.
1845 The elements of the Java model is only handles to the underlying elements. This
1846 means that the underlying element of a handle does not need to actually exist.
1847 Hence the user of a handle must always check that it exist by calling the
1848 \method{exists} method of the handle.
1850 The handles with descriptions is listed in \myref{tab:javaModel}.
1855 \newcolumntype{L}[1]{>{\hsize=#1\hsize\raggedright\arraybackslash}X}%
1856 % sum must equal number of columns (3)
1857 \begin{tabularx}{\textwidth}{| L{0.7} | L{1.1} | L{1.2} |}
1859 \textbf{Project Element} & \textbf{Java Model element} &
1860 \textbf{Description} \\
1862 Java project & \type{IJavaProject} & The Java project which contains all other objects. \\
1864 Source folder /\linebreak[2] binary folder /\linebreak[3] external library &
1865 \type{IPackageFragmentRoot} & Hold source or binary files, can be a folder
1866 or a library (zip / jar file). \\
1868 Each package & \type{IPackageFragment} & Each package is below the
1869 \type{IPackageFragmentRoot}, sub-packages are not leaves of the package,
1870 they are listed directed under \type{IPackageFragmentRoot}. \\
1872 Java Source file & \type{ICompilationUnit} & The Source file is always below
1873 the package node. \\
1875 Types /\linebreak[2] Fields /\linebreak[3] Methods & \type{IType} /
1877 \type{IField} /\linebreak[3] \type{IMethod} & Types, fields and methods. \\
1880 \caption{The elements of the Java Model. {\footnotesize Taken from
1881 \url{http://www.vogella.com/tutorials/EclipseJDT/article.html}}}
1882 \label{tab:javaModel}
1885 The hierarchy of the Java Model is shown in \myref{fig:javaModel}.
1889 \begin{tikzpicture}[%
1890 grow via three points={one child at (0,-0.7) and
1891 two children at (0,-0.7) and (0,-1.4)},
1892 edge from parent path={(\tikzparentnode.south west)+(0.5,0) |-
1893 (\tikzchildnode.west)}]
1894 \tikzstyle{every node}=[draw=black,thick,anchor=west]
1895 \tikzstyle{selected}=[draw=red,fill=red!30]
1896 \tikzstyle{optional}=[dashed,fill=gray!50]
1897 \node {\type{IJavaProject}}
1898 child { node {\type{IPackageFragmentRoot}}
1899 child { node {\type{IPackageFragment}}
1900 child { node {\type{ICompilationUnit}}
1901 child { node {\type{IType}}
1902 child { node {\type{\{ IType \}*}}
1903 child { node {\type{\ldots}}}
1906 child { node {\type{\{ IField \}*}}}
1907 child { node {\type{IMethod}}
1908 child { node {\type{\{ IType \}*}}
1909 child { node {\type{\ldots}}}
1914 child { node {\type{\{ IMethod \}*}}}
1923 child { node {\type{\{ IType \}*}}}
1934 child { node {\type{\{ ICompilationUnit \}*}}}
1947 child { node {\type{\{ IPackageFragment \}*}}}
1962 child { node {\type{\{ IPackageFragmentRoot \}*}}}
1965 \caption{The Java model of Eclipse. ``\type{\{ SomeElement \}*}'' means
1966 \type{SomeElement} zero or more times. For recursive structures,
1967 ``\type{\ldots}'' is used.}
1968 \label{fig:javaModel}
1971 \section{The Abstract Synax Tree}
1972 Eclipse is following the common paradigm of using an abstract syntaxt tree for
1973 source code analysis and manipulation.
1975 When parsing program source code into something that can be used as a foundation
1976 for analysis, the start of the process follows the same steps as in a compiler.
1977 This is all natural, because the way a compiler anayzes code is no different
1978 from how source manipulation programs would do it, except for some properties of
1979 code that is analyzed in the parser, and that they may be differing in what
1980 kinds of properties they analyze. Thus the process of translation source code
1981 into a structure that is suitable for analyzing, can be seen as a kind of
1982 interrupted compilation process \see{fig:interruptedCompilationProcess}.
1987 base/.style={anchor=north, align=center, rectangle, minimum height=1.4cm},
1988 basewithshadow/.style={base, drop shadow, fill=white},
1989 outlined/.style={basewithshadow, draw, rounded corners, minimum
1991 primary/.style={outlined, font=\bfseries},
1992 dashedbox/.style={outlined, dashed},
1993 arrowpath/.style={black, align=center, font=\small},
1994 processarrow/.style={arrowpath, ->, >=angle 90, shorten >=1pt},
1996 \begin{tikzpicture}[node distance=1.3cm and 3cm, scale=1, every
1997 node/.style={transform shape}]
1998 \node[base](AuxNode1){\small source code};
1999 \node[primary, right=of AuxNode1, xshift=-2.5cm](Scanner){Scanner};
2000 \node[primary, right=of Scanner, xshift=0.5cm](Parser){Parser};
2001 \node[dashedbox, below=of Parser](SemanticAnalyzer){Semantic\\Analyzer};
2002 \node[dashedbox, left=of SemanticAnalyzer](SourceCodeOptimizer){Source
2004 \node[dashedbox, below=of SourceCodeOptimizer
2005 ](CodeGenerator){Code\\Generator};
2006 \node[dashedbox, right=of CodeGenerator](TargetCodeOptimizer){Target
2008 \node[base, right=of TargetCodeOptimizer](AuxNode2){};
2010 \draw[processarrow](AuxNode1) -- (Scanner);
2012 \path[arrowpath] (Scanner) -- node [sloped](tokens){tokens}(Parser);
2013 \draw[processarrow](Scanner) -- (tokens) -- (Parser);
2015 \path[arrowpath] (Parser) -- node (syntax){syntax
2016 tree}(SemanticAnalyzer);
2017 \draw[processarrow](Parser) -- (syntax) -- (SemanticAnalyzer);
2019 \path[arrowpath] (SemanticAnalyzer) -- node
2020 [sloped](annotated){annotated\\tree}(SourceCodeOptimizer);
2021 \draw[processarrow, dashed](SemanticAnalyzer) -- (annotated) --
2022 (SourceCodeOptimizer);
2024 \path[arrowpath] (SourceCodeOptimizer) -- node
2025 (intermediate){intermediate code}(CodeGenerator);
2026 \draw[processarrow, dashed](SourceCodeOptimizer) -- (intermediate) --
2029 \path[arrowpath] (CodeGenerator) -- node [sloped](target1){target
2030 code}(TargetCodeOptimizer);
2031 \draw[processarrow, dashed](CodeGenerator) -- (target1) --
2032 (TargetCodeOptimizer);
2034 \path[arrowpath](TargetCodeOptimizer) -- node [sloped](target2){target
2036 \draw[processarrow, dashed](TargetCodeOptimizer) -- (target2) (AuxNode2);
2038 \caption{Interrupted compilation process. {\footnotesize (Full compilation
2039 process borrowed from \emph{Compiler construction: principles and practice}
2040 by Kenneth C. Louden\citing{louden1997}.)}}
2041 \label{fig:interruptedCompilationProcess}
2044 The process starts with a \emph{scanner}, or lexer. The job of the scanner is to
2045 read the source code and divide it into tokens for the parser. Therefore, it is
2046 also sometimes called a tokenizer. A token is a logical unit, defined in the
2047 language specification, consisting of one or more consecutive characters. In
2048 the java language the tokens can for instance be the \var{this} keyword, a curly
2049 bracket \var{\{} or a \var{nameToken}. It is recognized by the scanner on the
2050 basis of something eqivalent of a regular expression. This part of the process
2051 is often implemented with the use of a finite automata. In fact, it is common to
2052 specify the tokens in regular expressions, that in turn is translated into a
2053 finite automata lexer. This process can be automated.
2055 The program component used to translate a a stream of tokens into something
2056 meaningful, is called a parser. A parser is fed tokens from the scanner and
2057 performs an analysis of the structure of a program. It verifies that the syntax
2058 is correct according to the grammar rules of a language, that is usually
2059 specified in a context-free grammar, and often in a variant of the
2061 Form}\footnote{\url{https://en.wikipedia.org/wiki/Backus-Naur\_Form}}. The
2062 result coming from the parser is in the form of an \emph{Abstract Syntax Tree},
2063 AST for short. It is called \emph{abstract}, because the structure does not
2064 contain all of the tokens produced by the scanner. It only contain logical
2065 constructs, and because it forms a tree, all kinds of parentheses and brackets
2066 are implicit in the structure. It is this AST that is used when performing the
2067 semantic analysis of the code.
2069 As an example we can think of the expression \code{(5 + 7) * 2}. The root of
2070 this tree would in Eclipse be an \type{InfixExpression} with the operator
2071 \var{TIMES}, and a left operand that is also an \type{InfixExpression} with the
2072 operator \var{PLUS}. The left operand \type{InfixExpression}, has in turn a left
2073 operand of type \type{NumberLiteral} with the value \var{``5''} and a right
2074 operand \type{NumberLiteral} with the value \var{``7''}. The root will have a
2075 right operand of type \type{NumberLiteral} and value \var{``2''}. The AST for
2076 this expression is illustrated in \myref{fig:astInfixExpression}.
2078 Contrary to the Java Model, an abstract syntaxt tree is a heavy-weight
2079 representation of source code. It contains information about propertes like type
2080 bindings for variables and variable bindings for names.
2085 \begin{tikzpicture}[scale=0.8]
2086 \tikzset{level distance=40pt}
2087 \tikzset{sibling distance=5pt}
2088 \tikzstyle{thescale}=[scale=0.8]
2089 \tikzset{every tree node/.style={align=center}}
2090 \tikzset{edge from parent/.append style={thick}}
2091 \tikzstyle{inode}=[rectangle,rounded corners,draw,fill=lightgray,drop
2092 shadow,align=center]
2093 \tikzset{every internal node/.style={inode}}
2094 \tikzset{every leaf node/.style={draw=none,fill=none}}
2096 \Tree [.\type{InfixExpression} [.\type{InfixExpression}
2097 [.\type{NumberLiteral} \var{``5''} ] [.\type{Operator} \var{PLUS} ]
2098 [.\type{NumberLiteral} \var{``7''} ] ]
2099 [.\type{Operator} \var{TIMES} ]
2100 [.\type{NumberLiteral} \var{``2''} ]
2103 \caption{The abstract syntax tree for the expression \code{(5 + 7) * 2}.}
2104 \label{fig:astInfixExpression}
2107 \subsection{The AST in Eclipse}\label{astEclipse}
2108 In Eclipse, every node in the AST is a child of the abstract superclass
2109 \typewithref{org.eclipse.jdt.core.dom}{ASTNode}. Every \type{ASTNode}, among a
2110 lot of other things, provides information about its position and length in the
2111 source code, as well as a reference to its parent and to the root of the tree.
2113 The root of the AST is always of type \type{CompilationUnit}. It is not the same
2114 as an instance of an \type{ICompilationUnit}, which is the compilation unit
2115 handle of the Java model. The children of a \type{CompilationUnit} is an
2116 optional \type{PackageDeclaration}, zero or more nodes of type
2117 \type{ImportDecaration} and all its top-level type declarations that has node
2118 types \type{AbstractTypeDeclaration}.
2120 An \type{AbstractType\-Declaration} can be one of the types
2121 \type{AnnotationType\-Declaration}, \type{Enum\-Declaration} or
2122 \type{Type\-Declaration}. The children of an \type{AbstractType\-Declaration}
2123 must be a subtype of a \type{BodyDeclaration}. These subtypes are:
2124 \type{AnnotationTypeMember\-Declaration}, \type{EnumConstant\-Declaration},
2125 \type{Field\-Declaration}, \type{Initializer} and \type{Method\-Declaration}.
2127 Of the body declarations, the \type{Method\-Declaration} is the most interesting
2128 one. Its children include lists of modifiers, type parameters, parameters and
2129 exceptions. It has a return type node and a body node. The body, if present, is
2130 of type \type{Block}. A \type{Block} is itself a \type{Statement}, and its
2131 children is a list of \type{Statement} nodes.
2133 There are too many types of the abstract type \type{Statement} to list up, but
2134 there exists a subtype of \type{Statement} for every statement type of Java, as
2135 one would expect. This also applies to the abstract type \type{Expression}.
2136 However, the expression \type{Name} is a little special, since it is both used
2137 as an operand in compound expressions, as well as for names in type declarations
2140 There is an overview of some of the structure of an Eclipse AST in
2141 \myref{fig:astEclipse}.
2145 \begin{tikzpicture}[scale=0.8]
2146 \tikzset{level distance=50pt}
2147 \tikzset{sibling distance=5pt}
2148 \tikzstyle{thescale}=[scale=0.8]
2149 \tikzset{every tree node/.style={align=center}}
2150 \tikzset{edge from parent/.append style={thick}}
2151 \tikzstyle{inode}=[rectangle,rounded corners,draw,fill=lightgray,drop
2152 shadow,align=center]
2153 \tikzset{every internal node/.style={inode}}
2154 \tikzset{every leaf node/.style={draw=none,fill=none}}
2156 \Tree [.\type{CompilationUnit} [.\type{[ PackageDeclaration ]} [.\type{Name} ]
2157 [.\type{\{ Annotation \}*} ] ]
2158 [.\type{\{ ImportDeclaration \}*} [.\type{Name} ] ]
2159 [.\type{\{ AbstractTypeDeclaration \}+} [.\node(site){\type{\{
2160 BodyDeclaration \}*}}; ] [.\type{SimpleName} ] ]
2162 \begin{scope}[shift={(0.5,-6)}]
2163 \node[inode,thescale](root){\type{MethodDeclaration}};
2164 \node[inode,thescale](modifiers) at (4.5,-5){\type{\{ IExtendedModifier \}*}
2165 \\ {\footnotesize (Of type \type{Modifier} or \type{Annotation})}};
2166 \node[inode,thescale](typeParameters) at (-6,-3.5){\type{\{ TypeParameter
2168 \node[inode,thescale](parameters) at (-5,-5){\type{\{
2169 SingleVariableDeclaration \}*} \\ {\footnotesize (Parameters)}};
2170 \node[inode,thescale](exceptions) at (5,-3){\type{\{ Name \}*} \\
2171 {\footnotesize (Exceptions)}};
2172 \node[inode,thescale](return) at (-6.5,-2){\type{Type} \\ {\footnotesize
2174 \begin{scope}[shift={(0,-5)}]
2175 \Tree [.\node(body){\type{[ Block ]} \\ {\footnotesize (Body)}};
2176 [.\type{\{ Statement \}*} [.\type{\{ Expression \}*} ]
2177 [.\type{\{ Statement \}*} [.\type{\ldots} ]]
2182 \draw[->,>=triangle 90,shorten >=1pt](root.east)..controls +(east:2) and
2183 +(south:1)..(site.south);
2185 \draw (root.south) -- (modifiers);
2186 \draw (root.south) -- (typeParameters);
2187 \draw (root.south) -- ($ (parameters.north) + (2,0) $);
2188 \draw (root.south) -- (exceptions);
2189 \draw (root.south) -- (return);
2190 \draw (root.south) -- (body);
2193 \caption{The format of the abstract syntax tree in Eclipse.}
2194 \label{fig:astEclipse}
2196 \todoin{Add more to the AST format tree? \myref{fig:astEclipse}}
2198 \section{The ASTVisitor}\label{astVisitor}
2199 So far, the only thing that has been adressed is how the the data that is going
2200 to be the basis for our analysis is structured. Another aspect of it is how we
2201 are going to traverse the AST to gather the information we need, so we can
2202 conclude about the properties we are analysing. It is of course possible to
2203 start at the top of the tree, and manually search through its nodes for the ones
2204 we are looking for, but that is a bit inconvenient. To be able to efficiently
2205 utilize such an approach, we would need to make our own framework for traversing
2206 the tree and visiting only the types of nodes we are after. Luckily, this
2207 functionality is already provided in Eclipse, by its
2208 \typewithref{org.eclipse.jdt.core.dom}{ASTVisitor}.
2210 The Eclipse AST, together with its \type{ASTVisitor}, follows the \emph{Visitor}
2211 pattern\citing{designPatterns}. The intent of this design pattern is to
2212 facilitate extending the functionality of classes without touching the classes
2215 Let us say that there is a class hierarchy of \emph{Elements}. These elements
2216 all have a method \method{accept(Visitor visitor)}. In its simplest form, the
2217 \method{accept} method just calls the \method{visit} method of the visitor with
2218 itself as an argument, like this: \code{visitor.visit(this)}. For the visitors
2219 to be able to extend the functionality of all the classes in the elements
2220 hierarchy, each \type{Visitor} must have one visit method for each concrete
2221 class in the hierarchy. Say the hierarchy consists of the concrete classes
2222 \type{ConcreteElementA} and \type{ConcreteElementB}. Then each visitor must have
2223 the (possibly empty) methods \method{visit(ConcreteElementA element)} and
2224 \method{visit(ConcreteElementB element)}. This scenario is depicted in
2225 \myref{fig:visitorPattern}.
2229 \tikzstyle{abstract}=[rectangle, draw=black, fill=white, drop shadow, text
2230 centered, anchor=north, text=black, text width=6cm, every one node
2231 part/.style={align=center, font=\bfseries\itshape}]
2232 \tikzstyle{concrete}=[rectangle, draw=black, fill=white, drop shadow, text
2233 centered, anchor=north, text=black, text width=6cm]
2234 \tikzstyle{inheritarrow}=[->, >=open triangle 90, thick]
2235 \tikzstyle{commentarrow}=[->, >=angle 90, dashed]
2236 \tikzstyle{line}=[-, thick]
2237 \tikzset{every one node part/.style={align=center, font=\bfseries}}
2238 \tikzset{every second node part/.style={align=center, font=\ttfamily}}
2240 \begin{tikzpicture}[node distance=1cm, scale=0.8, every node/.style={transform
2242 \node (Element) [abstract, rectangle split, rectangle split parts=2]
2244 \nodepart{one}{Element}
2245 \nodepart{second}{+accept(visitor: Visitor)}
2247 \node (AuxNode01) [text width=0, minimum height=2cm, below=of Element] {};
2248 \node (ConcreteElementA) [concrete, rectangle split, rectangle split
2249 parts=2, left=of AuxNode01]
2251 \nodepart{one}{ConcreteElementA}
2252 \nodepart{second}{+accept(visitor: Visitor)}
2254 \node (ConcreteElementB) [concrete, rectangle split, rectangle split
2255 parts=2, right=of AuxNode01]
2257 \nodepart{one}{ConcreteElementB}
2258 \nodepart{second}{+accept(visitor: Visitor)}
2261 \node[comment, below=of ConcreteElementA] (CommentA) {visitor.visit(this)};
2263 \node[comment, below=of ConcreteElementB] (CommentB) {visitor.visit(this)};
2265 \node (AuxNodeX) [text width=0, minimum height=1cm, below=of AuxNode01] {};
2267 \node (Visitor) [abstract, rectangle split, rectangle split parts=2,
2270 \nodepart{one}{Visitor}
2271 \nodepart{second}{+visit(ConcreteElementA)\\+visit(ConcreteElementB)}
2273 \node (AuxNode02) [text width=0, minimum height=2cm, below=of Visitor] {};
2274 \node (ConcreteVisitor1) [concrete, rectangle split, rectangle split
2275 parts=2, left=of AuxNode02]
2277 \nodepart{one}{ConcreteVisitor1}
2278 \nodepart{second}{+visit(ConcreteElementA)\\+visit(ConcreteElementB)}
2280 \node (ConcreteVisitor2) [concrete, rectangle split, rectangle split
2281 parts=2, right=of AuxNode02]
2283 \nodepart{one}{ConcreteVisitor2}
2284 \nodepart{second}{+visit(ConcreteElementA)\\+visit(ConcreteElementB)}
2288 \draw[inheritarrow] (ConcreteElementA.north) -- ++(0,0.7) -|
2290 \draw[line] (ConcreteElementA.north) -- ++(0,0.7) -|
2291 (ConcreteElementB.north);
2293 \draw[inheritarrow] (ConcreteVisitor1.north) -- ++(0,0.7) -|
2295 \draw[line] (ConcreteVisitor1.north) -- ++(0,0.7) -|
2296 (ConcreteVisitor2.north);
2298 \draw[commentarrow] (CommentA.north) -- (ConcreteElementA.south);
2299 \draw[commentarrow] (CommentB.north) -- (ConcreteElementB.south);
2303 \caption{The Visitor Pattern.}
2304 \label{fig:visitorPattern}
2307 The use of the visitor pattern can be appropriate when the hierarchy of elements
2308 is mostly stable, but the family of operations over its elements is constantly
2309 growing. This is clearly the cas for the Eclipse AST, since the hierarchy of
2310 type \type{ASTNode} is very stable, but the functionality of its elements is
2311 extended every time someone needs to operate on the AST. Another aspect of the
2312 Eclipse implementation is that it is a public API, and the visitor pattern is an
2313 easy way to provide access to the nodes in the tree.
2315 The version of the visitor pattern implemented for the AST nodes in Eclipse also
2316 provides an elegant way to traverse the tree. It does so by following the
2317 convention that every node in the tree first let the visitor visit itself,
2318 before it also makes all its children accept the visitor. The children are only
2319 visited if the visit method of their parent returns \var{true}. This pattern
2320 then makes for a prefix traversal of the AST. If postfix traversal is desired,
2321 the visitors also has \method{endVisit} methods for each node type, that is
2322 called after the \method{visit} method for a node. In addition to these visit
2323 methods, there are also the methods \method{preVisit(ASTNode)},
2324 \method{postVisit(ASTNode)} and \method{preVisit2(ASTNode)}. The
2325 \method{preVisit} method is called before the type-specific \method{visit}
2326 method. The \method{postVisit} method is called after the type-specific
2327 \method{endVisit}. The type specific \method{visit} is only called if
2328 \method{preVisit2} returns \var{true}. Overriding the \method{preVisit2} is also
2329 altering the behavior of \method{preVisit}, since the default implementation is
2330 responsible for calling it.
2332 An example of a trivial \type{ASTVisitor} is shown in
2333 \myref{lst:astVisitorExample}.
2336 \begin{minted}{java}
2337 public class CollectNamesVisitor extends ASTVisitor {
2338 Collection<Name> names = new LinkedList<Name>();
2341 public boolean visit(QualifiedName node) {
2347 public boolean visit(SimpleName node) {
2353 \caption{An \type{ASTVisitor} that visits all the names in a subtree and adds
2354 them to a collection, except those names that are children of any
2355 \type{QualifiedName}.}
2356 \label{lst:astVisitorExample}
2359 \section{Property collectors}\label{propertyCollectors}
2360 The prefixes and unfixes are found by property
2361 collectors\typeref{no.uio.ifi.refaktor.extractors.collectors.PropertyCollector}.
2362 A property collector is of the \type{ASTVisitor} type, and thus visits nodes of
2363 type \type{ASTNode} of the abstract syntax tree \see{astVisitor}.
2365 \subsection{The PrefixesCollector}
2366 The \typewithref{no.uio.ifi.refaktor.extractors.collectors}{PrefixesCollector}
2367 finds prefixes that makes up the basis for calculating move targets for the
2368 Extract and Move Method refactoring. It visits expression
2369 statements\typeref{org.eclipse.jdt.core.dom.ExpressionStatement} and creates
2370 prefixes from its expressions in the case of method invocations. The prefixes
2371 found is registered with a prefix set, together with all its sub-prefixes.
2373 \subsection{The UnfixesCollector}\label{unfixes}
2374 The \typewithref{no.uio.ifi.refaktor.extractors.collectors}{UnfixesCollector}
2375 finds unfixes within a selection. That is prefixes that cannot be used as a
2376 basis for finding a move target in a refactoring.
2378 An unfix can be a name that is assigned to within a selection. The reason that
2379 this cannot be allowed, is that the result would be an assignment to the
2380 \type{this} keyword, which is not valid in Java \see{eclipse_bug_420726}.
2382 Prefixes that originates from variable declarations within the same selection
2383 are also considered unfixes. This is because when a method is moved, it needs to
2384 be called through a variable. If this variable is also within the method that is
2385 to be moved, this obviously cannot be done.
2387 Also considered as unfixes are variable references that are of types that is not
2388 suitable for moving a methods to. This can be either because it is not
2389 physically possible to move the method to the desired class or that it will
2390 cause compilation errors by doing so.
2392 If the type binding for a name is not resolved it is considered and unfix. The
2393 same applies to types that is only found in compiled code, so they have no
2394 underlying source that is accessible to us. (E.g. the \type{java.lang.String}
2397 Interfaces types are not suitable as targets. This is simply because interfaces
2398 in java cannot contain methods with bodies. (This thesis does not deal with
2399 features of Java versions later than Java 7. Java 8 has interfaces with default
2400 implementations of methods.) Neither are local types allowed. This accounts for
2401 both local and anonymous classes. Anonymous classes are effectively the same as
2402 interface types with respect to unfixes. Local classes could in theory be used
2403 as targets, but this is not possible due to limitations of the implementation of
2404 the Extract and Move Method refactoring. The problem is that the refactoring is
2405 done in two steps, so the intermediate state between the two refactorings would
2406 not be legal Java code. In the case of local classes, the problem is that, in
2407 the intermediate step, a selection referencing a local class would need to take
2408 the local class as a parameter if it were to be extracted to a new method. This
2409 new method would need to live in the scope of the declaring class of the
2410 originating method. The local class would then not be in the scope of the
2411 extracted method, thus bringing the source code into an illegal state. One could
2412 imagine that the method was extracted and moved in one operation, without an
2413 intermediate state. Then it would make sense to include variables with types of
2414 local classes in the set of legal targets, since the local classes would then be
2415 in the scopes of the method calls. If this makes any difference for software
2416 metrics that measure coupling would be a different discussion.
2419 \begin{multicols}{2}
2420 \begin{minted}[]{java}
2422 void declaresLocalClass() {
2437 \begin{minted}[]{java}
2438 // After Extract Method
2439 void declaresLocalClass() {
2450 // Intermediate step
2451 void fooBar(LocalClass inst) {
2457 \caption{When Extract and Move Method tries to use a variable with a local type
2458 as the move target, an intermediate step is taken that is not allowed. Here:
2459 \type{LocalClass} is not in the scope of \method{fooBar} in its intermediate
2461 \label{lst:extractMethod_LocalClass}
2464 The last class of names that are considered unfixes is names used in null tests.
2465 These are tests that reads like this: if \texttt{<name>} equals \var{null} then
2466 do something. If allowing variables used in those kinds of expressions as
2467 targets for moving methods, we would end up with code containing boolean
2468 expressions like \texttt{this == null}, which would not be meaningful, since
2469 \var{this} would never be \var{null}.
2472 \subsection{The ContainsReturnStatementCollector}
2474 \typewithref{no.uio.ifi.refaktor.analyze.collectors}{ContainsReturnStatementCollector}
2475 is a very simple property collector. It only visits the return statements within
2476 a selection, and can report whether it encountered a return statement or not.
2478 \subsection{The LastStatementCollector}
2479 The \typewithref{no.uio.ifi.refaktor.analyze.collectors}{LastStatementCollector}
2480 collects the last statement of a selection. It does so by only visiting the top
2481 level statements of the selection, and compares the textual end offset of each
2482 encuntered statement with the end offset of the previous statement found.
2484 \section{Checkers}\label{checkers}
2485 The checkers are a range of classes that checks that selections complies with
2486 certian criterias. If a
2487 \typewithref{no.uio.ifi.refaktor.analyze.analyzers}{Checker} fails, it throws a
2488 \type{CheckerException}. The checkers are managed by the
2489 \type{LegalStatementsChecker}, which does not, in fact, implement the
2490 \type{Checker} interface. It does, however, run all the checkers registered with
2491 it, and reports that all statements are considered legal if no
2492 \type{CheckerException} is thrown. Many of the checkers either extends the
2493 \type{PropertyCollector} or utilizes one or more property collectors to verify
2494 some criterias. The checkers registered with the \type{LegalStatementsChecker}
2495 are described next. They are run in the order presented below.
2497 \subsection{The EnclosingInstanceReferenceChecker}
2498 The purpose of this checker is to verify that the names in a selection is not
2499 referencing any enclosing instances. This is for making sure that all references
2500 is legal in a method that is to be moved. Theoretically, some situations could
2501 be easily solved my passing a reference to the referenced class with the moved
2502 method (e.g. when calling public methods), but the dependency on the
2503 \type{MoveInstanceMethodProcessor} prevents this.
2506 \typewithref{no.uio.ifi.refaktor.analyze.analyzers}{EnclosingInstanceReferenceChecker}
2507 is a modified version of the
2508 \typewithref{org.eclipse.jdt.internal.corext.refactoring.structure.MoveInstanceMethodProcessor}{EnclosingInstanceReferenceFinder}
2509 from the \type{MoveInstanceMethodProcessor}. Wherever the
2510 \type{EnclosingInstanceReferenceFinder} would create a fatal error status, the
2511 checker throws a \type{CheckerException}.
2513 It works by first finding all of the enclosing types of a selection. Thereafter
2514 it visits all its simple names to check that they are not references to
2515 variables or methods declared in any of the enclosing types. In addition the
2516 checker visits \var{this}-expressions to verify that no such expressions is
2517 qualified with any name.
2519 \subsection{The ReturnStatementsChecker}\label{returnStatementsChecker}
2520 \todoin{Write\ldots/change implementation/use control flow graph?}
2522 \subsection{The AmbiguousReturnValueChecker}
2523 This checker verifies that there are no \emph{ambiguous return statements} in a
2524 selection. The problem with ambiguous return statements arise when a selection
2525 is chosen to be extracted into a new method, but it needs to return more than
2526 one value from that method. This problem occurs in two situations. The first
2527 situation arise when there is more than one local variable that is both assigned
2528 to within a selection and also referenced after the selection. The other
2529 situation occur when there is only one such assignment, but there is also one or
2530 more return statements in the selection.
2532 First the checker needs to collect some data. Those data are the binding keys
2533 for all simple names that are assigned to within the selection, including
2534 variable declarations, but excluding fields. The checker also collects whether
2535 there exists a return statement in the selection or not. No further checks of
2536 return statements are needed, since, at this point, the selection is already
2537 checked for illegal return statements \see{returnStatementsChecker}.
2539 After the binding keys of the assignees are collected, the checker searches the
2540 part of the enclosing method that is after the selection for references whose
2541 binding keys are among the the collected keys. If more than one unique referral
2542 is found, or only one referral is found, but the selection also contains a
2543 return statement, we have a situation with an ambiguous return value, and an
2544 exception is thrown.
2546 %\todoin{Explain why we do not need to consider variables assigned inside
2547 %local/anonymous classes. (The referenced variables need to be final and so
2550 \subsection{The IllegalStatementsChecker}
2551 This checker is designed to check for illegal statements.
2553 Any use of the \var{super} keyword is prohibited, since its meaning is altered
2554 when moving a method to another class.
2556 For a \emph{break} statement, there is two situations to consider: A break
2557 statement with or without a label. If the break statement has a label, it is
2558 checked that whole of the labeled statement is inside the selection. Since a
2559 label does not have any binding information, we have to search upwards in the
2560 AST to find the \type{LabeledStatement} that corresponds to the label from the
2561 break statement, and check that it is contained in the selection. If the break
2562 statement does not have a label attached to it, it is checked that its innermost
2563 enclosing loop or switch statement also is inside the selection.
2565 The situation for a \emph{continue} statement is the same as for a break
2566 statement, except that it is not allowed inside switch statements.
2568 Regarding \emph{assignments}, two types of assignments is allowed: Assignment to
2569 a non-final variable and assignment to an array access. All other assignments is
2572 \todoin{Finish\ldots}
2575 \chapter{Benchmarking}
2576 \todoin{Better name than ``benchmarking''?}
2577 This part of the master project is located in the Eclipse project
2578 \code{no.uio.ifi.refaktor.benchmark}. The purpose of it is to run the equivalent
2579 of the \type{SearchBasedExtractAndMoveMethodChanger}
2580 \see{searchBasedExtractAndMoveMethodChanger} over a larger software project,
2581 both to test its roubustness but also its effect on different software metrics.
2583 \section{The benchmark setup}
2584 The benchmark itself is set up as a \emph{JUnit} test case. This is a convenient
2585 setup, and utilizes the \emph{JUnit Plugin Test Launcher}. This provides us a
2586 with a fully functional Eclipse workbench. Most importantly, this gives us
2587 access to the Java Model of Eclipse \see{javaModel}.
2589 \subsection{The ProjectImporter}
2590 The Java project that is going to be used as the data for the benchmark, must be
2591 imported into the JUnit workspace. This is done by the
2592 \typewithref{no.uio.ifi.refaktor.benchmark}{ProjectImporter}. The importer
2593 require the absolute path to the project description file. It is named
2594 \code{.project} and is located at the root of the project directory.
2596 The project description is loaded to find the name of the project to be
2597 imported. The project that shall be the destination for the import is created in
2598 the workspace, on the base of the name from the description. Then an import
2599 operation is created, based on both the source and destination information. The
2600 import operation is run to perform the import.
2602 I have found no simple API call to accomplish what the importer does, which
2603 tells me that it may not be too many people performing this particular action.
2604 The solution to the problem was found on \emph{Stack
2605 Overflow}\footnote{\url{https://stackoverflow.com/questions/12401297}}. It
2606 contains enough dirty details to be considered unconvenient to use, if not
2607 wrapping it in a class like my \type{ProjectImporter}. One would probably have
2608 to delve into the source code for the import wizard to find out how the import
2609 operation works, if no one had already done it.
2611 \section{Statistics}
2612 Statistics for the analysis and changes is captured by the
2613 \typewithref{no.uio.ifi.refaktor.aspects}{StatisticsAspect}. This an
2614 \emph{aspect} written in \emph{AspectJ}.
2616 \subsection{AspectJ}
2617 \emph{AspectJ}\footnote{\url{http://eclipse.org/aspectj/}} is an extension to
2618 the Java language, and facilitates combining aspect-oriented programming with
2619 the object-oriented programming in Java.
2621 Aspect-oriented programming is a programming paradigm that is meant to isolate
2622 so-called \emph{cross-cutting concerns} into their own modules. These
2623 cross-cutting concerns are functionalities that spans over multiple classes, but
2624 may not belong naturally in any of them. It can be functionality that does not
2625 concern the business logic of an application, and thus may be a burden when
2626 entangled with parts of the source code it does not really belong. Examples
2627 include logging, debugging, optimization and security.
2629 Aspects are interacting with other modules by defining advices. The concept of
2630 an \emph{advice} is known from both aspect-oriented and functional
2631 programming\citing{wikiAdvice2014}. It is a function that modifies another
2632 function when the latter is run. An advice in AspectJ is somewhat similar to a
2633 method in Java. It is meant to alter the behavior of other methods, and contains
2634 a body that is executed when it is applied.
2636 An advice can be applied at a defined \emph{pointcut}. A pointcut picks out one
2637 or more \emph{join points}. A join point is a well-defined point in the
2638 execution of a program. It can occur when calling a method defined for a
2639 particular class, when calling all methods with the same name,
2640 accessing/assigning to a particular field of a given class and so on. An advice
2641 can be declared to run both before, after returning from a pointcut, when there
2642 is thrown an exception in the pointcut or after the pointcut either returns or
2643 throws an exception. In addition to picking out join points, a pointcut can
2644 also bind variables from its context, so they can be accessed in the body of an
2645 advice. An example of a pointcut and an advice is found in
2646 \myref{lst:aspectjExample}.
2649 \begin{minted}{aspectj}
2650 pointcut methodAnalyze(
2651 SearchBasedExtractAndMoveMethodAnalyzer analyzer) :
2652 call(* SearchBasedExtractAndMoveMethodAnalyzer.analyze())
2653 && target(analyzer);
2655 after(SearchBasedExtractAndMoveMethodAnalyzer analyzer) :
2656 methodAnalyze(analyzer) {
2657 statistics.methodCount++;
2658 debugPrintMethodAnalysisProgress(analyzer.method);
2661 \caption{An example of a pointcut named \method{methodAnalyze},
2662 and an advice defined to be applied after it has occurred.}
2663 \label{lst:aspectjExample}
2666 \subsection{The Statistics class}
2667 The statistics aspect stores statistical information in an object of type
2668 \type{Statistics}. As of now, the aspect needs to be initialized at the point in
2669 time where it is desired that it starts its data gathering. At any point in time
2670 the statistics aspect can be queried for a snapshot of the current statistics.
2672 The \type{Statistics} class also include functionality for generating a report
2673 of its gathered statistics. The report can be given either as a string or it can
2674 be written to a file.
2676 \subsection{Advices}
2677 The statistics aspect contains advices for gathering statistical data from
2678 different parts of the benchmarking process. It captures statistics from both
2679 the analysis part and the execution part of the composite \ExtractAndMoveMethod
2682 For the analysis part, there are advices to count the number of text selections
2683 analyzed and the number of methods, types, compilation units and packages
2684 analyzed. There are also advices that counts for how many of the methods there
2685 is found a selection that is a candidate for the refactoring, and for how many
2686 ethods there is not.
2688 There exists advices for counting both the successful and unsuccessful
2689 executions of all the refactorings. Both for the \ExtractMethod and \MoveMethod
2690 refactorings in isolation, as well as for the combination of them.
2692 \section{Optimizations}
2693 When looking for optimizations to make for the benchmarking process, I used the
2694 \emph{VisualVM}\footnote{\url{http://visualvm.java.net/}} for the Java Virtual
2695 Machine to both profile the application and also to make memory dumps of its
2698 \subsection{Caching}
2699 When profiling the benchmark process before making any optimizations, it early
2700 became apparent that the parsing of source code was a place to direct attention
2701 towards. This discovery was done when only \emph{analyzing} source code, before
2702 trying to do any \emph{manipulation} of it. Caching of the parsed ASTs seemed
2703 like the best way to save some time, as expected. With only a simple cache of
2704 the most recently used AST, the analysis time was speeded up by a factor of
2706 20. This number depends a little upon which type of system the analysis was
2709 The caching is managed by a cache manager, that now, by default, utilizes the
2710 not so well known feature of Java called a \emph{soft reference}. Soft
2711 references are best explained in the context of weak references. A \emph{weak
2712 reference} is a reference to an object instance that is only guaranteed to
2713 persist as long as there is a \emph{strong reference} or a soft reference
2714 referring the same object. If no such reference is found, its referred object is
2715 garbage collected. A strong reference is basically the same as a regular Java
2716 reference. A soft reference has the same guarantees as a week reference when it
2717 comes to its relation to strong references, but it is not necessarily garbage
2718 collected whenever there exists no strong references to it. A soft reference
2719 \emph{may} reside in memory as long as the JVM has enough free memory in the
2720 heap. A soft reference will therefore usually perform better than a weak
2721 reference when used for simple caching and similar tasks. The way to use a
2722 soft/weak reference is to as it for its referent. The return value then has to
2723 be tested to check that it is not \var{null}. For the basic usage of soft
2724 references, see \myref{lst:softReferenceExample}. For a more thorough
2725 explanation of weak references in general, see\citing{weakRef2006}.
2728 \begin{minted}{java}
2730 Object strongRef = new Object();
2733 SoftReference<Object> softRef =
2734 new SoftReference<Object>(new Object());
2736 // Using the soft reference
2737 Object obj = softRef.get();
2742 \caption{Showing the basic usage of soft references. Weak references is used the
2743 same way. {\footnotesize (The references are part of the \code{java.lang.ref}
2745 \label{lst:softReferenceExample}
2748 The cache based on soft references has no limit for how many ASTs it caches. It
2749 is generally not advisable to keep references to ASTs for prolonged periods of
2750 time, since they are expensive structures to hold on to. For regular plugin
2751 development, Eclipse recommends not creating more than one AST at a time to
2752 limit memory consumption. Since the benchmarking has nothing to do with user
2753 experience, and throughput is everything, these advices are intentionally
2754 ignored. This means that during the benchmarking process, the target Eclipse
2755 application may very well work close to its memory limit for the heap space for
2756 long periods during the benchmark.
2758 \subsection{Memento}
2760 \chapter{Eclipse Bugs Found}
2761 \todoin{Add other things and change headline?}
2763 \section{Eclipse bug 420726: Code is broken when moving a method that is
2764 assigning to the parameter that is also the move
2765 destination}\label{eclipse_bug_420726}
2766 This bug\footnote{\url{https://bugs.eclipse.org/bugs/show\_bug.cgi?id=420726}}
2767 was found when analyzing what kinds of names that was to be considered as
2768 \emph{unfixes} \see{unfixes}.
2770 \subsection{The bug}
2771 The bug emerges when trying to move a method from one class to another, and when
2772 the target for the move (must be a variable, local or field) is both a parameter
2773 variable and also is assigned to within the method body. Eclipse allows this to
2774 happen, although it is the sure path to a compilation error. This is because we
2775 would then have an assignment to a \var{this} expression, which is not allowed
2778 \subsection{The solution}
2779 The solution to this problem is to add all simple names that are assigned to in
2780 a method body to the set of unfixes.
2782 \section{Eclipse bug 429416: IAE when moving method from anonymous class}
2784 discovered\footnote{\url{https://bugs.eclipse.org/bugs/show\_bug.cgi?id=429416}}
2785 this bug during a batch change on the \type{org.eclipse.jdt.ui} project.
2787 \subsection{The bug}
2788 This bug surfaces when trying to use the Move Method refactoring to move a
2789 method from an anonymous class to another class. This happens both for my
2790 simulation as well as in Eclipse, through the user interface. It only occurs
2791 when Eclipse analyzes the program and finds it necessary to pass an instance of
2792 the originating class as a parameter to the moved method. I.e. it want to pass a
2793 \var{this} expression. The execution ends in an
2794 \typewithref{java.lang}{IllegalArgumentException} in
2795 \typewithref{org.eclipse.jdt.core.dom}{SimpleName} and its
2796 \method{setIdentifier(String)} method. The simple name is attempted created in
2798 \methodwithref{org.eclipse.jdt.internal.corext.refactoring.structure.\\MoveInstanceMethodProcessor}{createInlinedMethodInvocation}
2799 so the \type{MoveInstanceMethodProcessor} was early a clear suspect.
2801 The \method{createInlinedMethodInvocation} is the method that creates a method
2802 invocation where the previous invocation to the method that was moved was. From
2803 its code it can be read that when a \var{this} expression is going to be passed
2804 in to the invocation, it shall be qualified with the name of the original
2805 method's declaring class, if the declaring class is either an anonymous clas or
2806 a member class. The problem with this, is that an anonymous class does not have
2807 a name, hence the term \emph{anonymous} class! Therefore, when its name, an
2808 empty string, is passed into
2809 \methodwithref{org.eclipse.jdt.core.dom.AST}{newSimpleName} it all ends in an
2810 \type{IllegalArgumentException}.
2812 \subsection{How I solved the problem}
2813 Since the \type{MoveInstanceMethodProcessor} is instantiated in the
2814 \typewithref{no.uio.ifi.refaktor.change.executors}{MoveMethod\-RefactoringExecutor},
2815 and only need to be a
2816 \typewithref{org.eclipse.ltk.core.refactoring.participants}{MoveProcessor}, I
2817 was able to copy the code for the original move processor and modify it so that
2818 it works better for me. It is now called
2819 \typewithref{no.uio.ifi.refaktor.refactorings.processors}{ModifiedMoveInstanceMethodProcessor}.
2820 The only modification done (in addition to some imports and suppression of
2821 warnings), is in the \method{createInlinedMethodInvocation}. When the declaring
2822 class of the method to move is anonymous, the \var{this} expression in the
2823 parameter list is not qualified with the declaring class' (empty) name.
2825 \section{Eclipse bug 429954: Extracting statement with reference to local type
2826 breaks code}\label{eclipse_bug_429954}
2827 The bug\footnote{\url{https://bugs.eclipse.org/bugs/show\_bug.cgi?id=429954}}
2828 was discovered when doing some changes to the way unfixes is computed.
2830 \subsection{The bug}
2831 The problem is that Eclipse is allowing selections that references variables of
2832 local types to be extracted. When this happens the code is broken, since the
2833 extracted method must take a parameter of a local type that is not in the
2834 methods scope. The problem is illustrated in
2835 \myref{lst:extractMethod_LocalClass}, but there in another setting.
2837 \subsection{Actions taken}
2838 There are no actions directly springing out of this bug, since the Extract
2839 Method refactoring cannot be meant to be this way. This is handled on the
2840 analysis stage of our Extract and Move Method refactoring. So names representing
2841 variables of local types is considered unfixes \see{unfixes}.
2842 \todoin{write more when fixing this in legal statements checker}
2844 \chapter{Related Work}
2846 \section{The compositional paradigm of refactoring}
2847 This paradigm builds upon the observation of Vakilian et
2848 al.\citing{vakilian2012}, that of the many automated refactorings existing in
2849 modern IDEs, the simplest ones are dominating the usage statistics. The report
2850 mainly focuses on \emph{Eclipse} as the tool under investigation.
2852 The paradigm is described almost as the opposite of automated composition of
2853 refactorings \see{compositeRefactorings}. It works by providing the programmer
2854 with easily accessible primitive refactorings. These refactorings shall be
2855 accessed via keyboard shortcuts or quick-assist menus\footnote{Think
2856 quick-assist with Ctrl+1 in Eclipse} and be promptly executed, opposed to in the
2857 currently dominating wizard-based refactoring paradigm. They are ment to
2858 stimulate composing smaller refactorings into more complex changes, rather than
2859 doing a large upfront configuration of a wizard-based refactoring, before
2860 previewing and executing it. The compositional paradigm of refactoring is
2861 supposed to give control back to the programmer, by supporting \himher with an
2862 option of performing small rapid changes instead of large changes with a lesser
2863 degree of control. The report authors hope this will lead to fewer unsuccessful
2864 refactorings. It also could lower the bar for understanding the steps of a
2865 larger composite refactoring and thus also help in figuring out what goes wrong
2866 if one should choose to op in on a wizard-based refactoring.
2868 Vakilian and his associates have performed a survey of the effectiveness of the
2869 compositional paradigm versus the wizard-based one. They claim to have found
2870 evidence of that the \emph{compositional paradigm} outperforms the
2871 \emph{wizard-based}. It does so by reducing automation, which seem
2872 counterintuitive. Therefore they ask the question ``What is an appropriate level
2873 of automation?'', and thus questions what they feel is a rush toward more
2874 automation in the software engineering community.