\usepackage{babel,textcomp,csquotes,ifimasterforside,varioref}
\usepackage[hidelinks]{hyperref}
\usepackage{cleveref}
-\usepackage[style=numeric-comp,backend=bibtex]{biblatex}
+\usepackage[style=alphabetic,backend=bibtex]{biblatex}
\usepackage{amsthm}
\usepackage{graphicx}
% use 'disable' before printing:
also present in the Forth\footnote{\emph{Forth} -- stack-based, extensible
programming language, without type-checking. See \url{http://www.forth.org}}
community, and the word ``refactoring'' is mentioned in a book by Leo Brodie,
-called \emph{Thinking Forth}\citing{brodie1984}, first published in
+called \emph{Thinking Forth}\citing{brodie2004}, first published in
1984\footnote{\emph{Thinking Forth} was first published in 1984 by the
\emph{Forth Interest Group}. Then it was reprinted in 1994 with minor
typographical corrections, before it was transcribed into an electronic edition
typeset in \LaTeX\ and published under a Creative Commons licence in 2004. The
edition cited here is the 2004 edition, but the content should essentially be as
-in 1984.}. The exact word is only printed one place~\cite[p.~232]{brodie1984},
+in 1984.}. The exact word is only printed one place~\cite[p.~232]{brodie2004},
but the term \emph{factoring} is prominent in the book, that also contains a
whole chapter dedicated to (re)factoring, and how to keep the (Forth) code clean
and maintainable.
\begin{quote}
\ldots good factoring technique is perhaps the most important skill for a
- Forth programmer.~\cite[p.~172]{brodie1984}
+ Forth programmer.~\cite[p.~172]{brodie2004}
\end{quote}
\noindent Brodie also express what \emph{factoring} means to him:
Factoring means organizing code into useful fragments. To make a fragment
useful, you often must separate reusable parts from non-reusable parts. The
reusable parts become new definitions. The non-reusable parts become arguments
- or parameters to the definitions.~\cite[p.~172]{brodie1984}
+ or parameters to the definitions.~\cite[p.~172]{brodie2004}
\end{quote}
Fowler claims that the usage of the word \emph{refactoring} did not pass between
present an example of an \ExtractMethod refactoring followed by a \MoveMethod
refactoring that breaks a program in both the \emph{Eclipse} and \emph{IntelliJ}
IDEs\footnote{The NetBeans IDE handles this particular situation without
- altering ther program's beavior, mainly because its Move Method refactoring
- implementation is a bit rancid in other ways \see{toolSupport}.}. The
+ altering the program's beavior, mainly because its Move Method refactoring
+ implementation is a bit flawed in other ways \see{toolSupport}.}. The
following piece of code shows the target for the composed refactoring:
\begin{minted}[linenos,samepage]{java}
only suitable to test the \emph{result} of isolated operations. They can not
easily (if at all) observe the \emph{history} of a program.
+This problem is still open.
-\todoin{Write \ldots}
+\todoin{Write?}
+\begin{comment}
Assuming a sequential (non-concurrent) program:
% { assert x1 != x2; }
%}
%\end{minted}
+\end{comment}
\section{The project}
-The aim of this project will be to investigate the relationship between a
+The aim of this master project will be to investigate the relationship between a
composite refactoring composed of the \ExtractMethod and \MoveMethod
refactorings, and its impact on one or more software metrics.
-The composition of \ExtractMethod and \MoveMethod springs naturally out of the
-need to move procedures closer to the data they manipulate. This composed
-refactoring is not well described in the literature, but it is implemented in at
-least one tool called
+The composition of the \ExtractMethod and \MoveMethod refactorings springs
+naturally out of the need to move procedures closer to the data they manipulate.
+This composed refactoring is not well described in the literature, but it is
+implemented in at least one tool called
\emph{CodeRush}\footnote{\url{https://help.devexpress.com/\#CodeRush/CustomDocument3519}},
that is an extension for \emph{MS Visual
Studio}\footnote{\url{http://www.visualstudio.com/}}. In CodeRush it is called
automatically I have to make it analyze code to determine the best selections to
extract into new methods.
-\section{Software metrics}
-\todoin{Is this the appropriate place to have this section?}
%\part{The project}
%\chapter{Planning the project}
-\chapter{\ldots}
-\todoin{write}
+\chapter{The Project}
+
\section{The problem statement}
+\todoin{write/move}
+
\section{Choosing the target language}
-Choosing which programming language to use as the target for manipulation is not
-a very difficult task. The language has to be an object-oriented programming
-language, and it must have existing tool support for refactoring. The
-\emph{Java} programming language\footnote{\url{https://www.java.com/}} is the
-dominating language when it comes to examples in the literature of refactoring,
-and is thus a natural choice. Java is perhaps, currently the most influential
-programming language in the world, with its \emph{Java Virtual Machine} that
-runs on all of the most popular architectures and also supports\footnote{They
-compile to java bytecode.} dozens of other programming languages, with
-\emph{Scala}, \emph{Clojure} and \emph{Groovy} as the most prominent ones. Java
-is currently the language that every other programming language is compared
-against. It is also the primary language of the author of this thesis.
+Choosing which programming language the code that shall be manipulated shall be
+written in, is not a very difficult task. We choose to limit the possible
+languages to the object-oriented programming languages, since most of the
+terminology and literature regarding refactoring comes from the world of
+object-oriented programming. In addition, the language must have existing tool
+support for refactoring.
+
+The \emph{Java} programming language\footnote{\url{https://www.java.com/}} is
+the dominating language when it comes to example code in the literature of
+refactoring, and is thus a natural choice. Java is perhaps, currently the most
+influential programming language in the world, with its \emph{Java Virtual
+Machine} that runs on all of the most popular architectures and also supports
+dozens of other programming languages\footnote{They compile to java bytecode.},
+with \emph{Scala}, \emph{Clojure} and \emph{Groovy} as the most prominent ones.
+Java is currently the language that every other programming language is compared
+against. It is also the primary programming language for the author of this
+thesis.
\section{Choosing the tools}
When choosing a tool for manipulating Java, there are certain criterias that
popular\citing{javaReport2011} among them and seems to be de facto standard IDE
for Java development regardless of platform.
+\section{Organizing the project}
+All the parts of this master project is under version control with
+\emph{Git}\footnote{\url{http://git-scm.com/}}.
+
+The software written is organized as some Eclipse plugins. Writing a plugin is
+the natural way to utilize the API of Eclipse. This also makes it possible to
+provide a user interface to manually run operations on selections in program
+source code or whole projects/packages.
+
+When writing a plugin in Eclipse, one has access to resources such as the
+current workspace, the open editor and the current selection.
+
+\section{Continuous integration}
+The continuous integration server
+\emph{Jenkins}\footnote{\url{http://jenkins-ci.org/}} has been set up for the
+project\footnote{A work mostly done by the supervisor.}. It is used as a way to
+run tests and perform code coverage analysis.
+
+To be able to build the Eclipse plugins and run tests for them with Jenkins, the
+component assembly project
+\emph{Buckminster}\footnote{\url{http://www.eclipse.org/buckminster/}} is used,
+through its plugin for Jenkins. Buckminster provides for a way to specify the
+resources needed for building a project and where and how to find them.
+Buckminster also handles the setup of a target environment to run the tests in.
+All this is needed because the code to build depends on an Eclipse installation
+with various plugins.
+
+\subsection{Problems with AspectJ}
+The Buckminster build worked fine until introducing AspectJ into the project.
+When building projects using AspectJ, there are some additional steps that needs
+to be performed. First of all, the aspects themselves must be compiled. Then the
+aspects needs to be woven with the classes they affect. This demands a process
+that does multiple passes over the source code.
+
+When using AspectJ with Eclipse, the specialized compilation and the weaving can
+be handled by the \emph{AspectJ Development
+Tools}\footnote{\url{https://www.eclipse.org/ajdt/}}. This works all fine, but
+it complicates things when trying to build a project depending on Eclipse
+plugins outside of Eclipse. There is supposed to be a way to specify a compiler
+adapter for javac, together with the file extensions for the file types it shall
+operate. The AspectJ compiler adapter is called
+\typewithref{org.aspectj.tools.ant.taskdefs}{Ajc11CompilerAdapter}, and it works
+with files that has the extensions \code{*.java} and \code{*.aj}. I tried to
+setup this in the build properties file for the project containing the aspects,
+but to no avail. The project containing the aspects does not seem to be built at
+all, and the projects that depends on it complains that they cannot find certain
+classes.
+
+I then managed to write an \emph{Ant}\footnote{\url{https://ant.apache.org/}}
+build file that utilizes the AspectJ compiler adapter, for the
+\code{no.uio.ifi.refaktor} plugin. The problem was then that it could no longer
+take advantage of the environment set up by Buckminster. The solution to this
+particular problem was of a ``hacky'' nature. It involves exporting the plugin
+dependencies for the project to an Ant build file, and copy the exported path
+into the existing build script. But then the Ant script needs to know where the
+local Eclipse installation is located. This is no problem when building on a
+local machine, but to utilize the setup done by Buckminster is a problem still
+unsolved. To get the classpath for the build setup correctly, and here comes the
+most ``hacky'' part of the solution, the Ant script has a target for copying the
+classpath elements into a directory relative to the project directory and
+checking it into Git. When no \code{ECLIPSE\_HOME} property is set while running
+Ant, the script uses the copied plugins instead of the ones provided by the
+Eclipse installation when building the project. This obviously creates some
+problems with maintaining the list of dependencies in the Ant file, as well as
+remembering to copy the plugins every time the list of dependencies change.
+
+The Ant script described above is run by Jenkins before the Buckminster setup
+and build. When setup like this, the Buckminster build succeeds for the projects
+not using AspectJ, and the tests are run as normal. This is all good, but it
+feels a little scary, since the reason for Buckminster not working with AspectJ
+is still unknown.
+
+The problems with building with AspectJ on the Jenkins server lasted for a
+while, before they were solved. This is reflected in the ``Test Result Trend''
+and ``Code Coverage Trend'' reported by Jenkins.
+
\chapter{Refactorings in Eclipse JDT: Design, Shortcomings and Wishful
Thinking}\label{ch:jdt_refactorings}
\todo{What about the language specific part?}
\subsection{The Language Toolkit}
-The Language Toolkit, or LTK for short, is the framework that is used to
-implement refactorings in Eclipse. It is language independent and provides the
-abstractions of a refactoring and the change it generates, in the form of the
-classes \typewithref{org.eclipse.ltk.core.refactoring}{Refactoring} and
-\typewithref{org.eclipse.ltk.core.refactoring}{Change}. (There is also parts of
-the LTK that is concerned with user interaction, but they will not be discussed
-here, since they are of little value to us and our use of the framework.)
+The Language Toolkit\footnote{The content of this section is a mixture of
+ written material from
+ \url{https://www.eclipse.org/articles/Article-LTK/ltk.html} and
+ \url{http://www.eclipse.org/articles/article.php?file=Article-Unleashing-the-Power-of-Refactoring/index.html},
+the LTK source code and my own memory.}, or LTK for short, is the framework that
+is used to implement refactorings in Eclipse. It is language independent and
+provides the abstractions of a refactoring and the change it generates, in the
+form of the classes \typewithref{org.eclipse.ltk.core.refactoring}{Refactoring}
+and \typewithref{org.eclipse.ltk.core.refactoring}{Change}.
+
+There are also parts of the LTK that is concerned with user interaction, but
+they will not be discussed here, since they are of little value to us and our
+use of the framework. We are primarily interested in the parts that can be
+automated.
\subsubsection{The Refactoring Class}
The abstract class \type{Refactoring} is the core of the LTK framework. Every
refactoring\typeref{org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring}.
It then delegates to its given
\typewithref{org.eclipse.ltk.core.refactoring.participants}{RefactoringProcessor}
-for condition checking and change creation.
+for condition checking and change creation. Participating in a refactoring can
+be useful in cases where the changes done to programming source code affects
+other related resources in the workspace. This can be names or paths in
+configuration files, or maybe one would like to perform additional logging of
+changes done in the workspace.
\subsubsection{The Change Class}
This class is the base class for objects that is responsible for performing the
\subsubsection{Missing Flexibility from JDT Refactorings}
The JDT refactorings are not made with composition of refactorings in mind. When
a JDT refactoring is executed, it assumes that all conditions for it to be
-applied successfully can be found by reading source files that has been
+applied successfully can be found by reading source files that have been
persisted to disk. They can only operate on the actual source material, and not
(in-memory) copies thereof. This constitutes a major disadvantage when trying to
-compose refactorings, since if an exception occur in the middle of a sequence of
-refactorings, it can leave the project in a state where the composite
-refactoring was executed only partly. It makes it hard to discard the changes
+compose refactorings, since if an exception occurs in the middle of a sequence
+of refactorings, it can leave the project in a state where the composite
+refactoring was only partially executed. It makes it hard to discard the changes
done without monitoring and consulting the undo manager, an approach that is not
bullet proof.
To make a working refactoring from the processor, one have to create a
\type{MoveRefactoring} with it.
-\subsection{The ExtractAndMoveMethodChanger Class}
+\subsection{The ExtractAndMoveMethodChanger}
The \typewithref{no.uio.ifi.refaktor.changers}{ExtractAndMoveMethodChanger}
class is a subclass of the class
is provided by the parameter information object.
+\subsection{The
+SearchBasedExtractAndMoveMethodChanger}\label{searchBasedExtractAndMoveMethodChanger}
+\todoin{Write\ldots}
+
\subsection{Finding the IMethod}\label{postExtractExecution}
-\todoin{Rename section. Write.}
+\todoin{Rename section. Write??}
\subsection{The Prefix Class}
\chapter{Analyzing Source Code in Eclipse}
-\section{The Java model}
+\section{The Java model}\label{javaModel}
The Java model of Eclipse is its internal representation of a Java project. It
is light-weight, and has only limited possibilities for manipulating source
code. It is typically used as a basis for the Package Explorer in Eclipse.
Hence the user of a handle must always check that it exist by calling the
\method{exists} method of the handle.
-The handles with descriptions is listed in \myref{tab:javaModelTable}.
+The handles with descriptions is listed in \myref{tab:javaModel}.
\begin{table}[h]
\centering
\end{tabularx}
\caption{The elements of the Java Model. {\footnotesize Taken from
\url{http://www.vogella.com/tutorials/EclipseJDT/article.html}}}
- \label{tab:javaModelTable}
+ \label{tab:javaModel}
\end{table}
The hierarchy of the Java Model is shown in \myref{fig:javaModel}.
\todoin{Finish\ldots}
+
+\chapter{Benchmarking}
+\todoin{Better name than ``benchmarking''?}
+This part of the master project is located in the Eclipse project
+\code{no.uio.ifi.refaktor.benchmark}. The purpose of it is to run the equivalent
+of the \type{SearchBasedExtractAndMoveMethodChanger}
+\see{searchBasedExtractAndMoveMethodChanger} over a larger software project,
+both to test its roubustness but also its effect on different software metrics.
+
+\section{The benchmark setup}
+The benchmark itself is set up as a \emph{JUnit} test case. This is a convenient
+setup, and utilizes the \emph{JUnit Plugin Test Launcher}. This provides us a
+with a fully functional Eclipse workbench. Most importantly, this gives us
+access to the Java Model of Eclipse \see{javaModel}.
+
+\subsection{The ProjectImporter}
+The Java project that is going to be used as the data for the benchmark, must be
+imported into the JUnit workspace. This is done by the
+\typewithref{no.uio.ifi.refaktor.benchmark}{ProjectImporter}. The importer
+require the absolute path to the project description file. It is named
+\code{.project} and is located at the root of the project directory.
+
+The project description is loaded to find the name of the project to be
+imported. The project that shall be the destination for the import is created in
+the workspace, on the base of the name from the description. Then an import
+operation is created, based on both the source and destination information. The
+import operation is run to perform the import.
+
+I have found no simple API call to accomplish what the importer does, which
+tells me that it may not be too many people performing this particular action.
+The solution to the problem was found on \emph{Stack
+Overflow}\footnote{\url{https://stackoverflow.com/questions/12401297}}. It
+contains enough dirty details to be considered unconvenient to use, if not
+wrapping it in a class like my \type{ProjectImporter}. One would probably have
+to delve into the source code for the import wizard to find out how the import
+operation works, if no one had already done it.
+
+\section{Statistics}
+Statistics for the analysis and changes is captured by the
+\typewithref{no.uio.ifi.refaktor.aspects}{StatisticsAspect}. This an
+\emph{aspect} written in \emph{AspectJ}.
+
+\subsection{AspectJ}
+\emph{AspectJ}\footnote{\url{http://eclipse.org/aspectj/}} is an extension to
+the Java language, and facilitates combining aspect-oriented programming with
+the object-oriented programming in Java.
+
+Aspect-oriented programming is a programming paradigm that is meant to isolate
+so-called \emph{cross-cutting concerns} into their own modules. These
+cross-cutting concerns are functionalities that spans over multiple classes, but
+may not belong naturally in any of them. It can be functionality that does not
+concern the business logic of an application, and thus may be a burden when
+entangled with parts of the source code it does not really belong. Examples
+include logging, debugging, optimization and security.
+
+Aspects are interacting with other modules by defining advices. The concept of
+an \emph{advice} is known from both aspect-oriented and functional
+programming\citing{wikiAdvice2014}. It is a function that modifies another
+function when the latter is run. An advice in AspectJ is somewhat similar to a
+method in Java. It is meant to alter the behavior of other methods, and contains
+a body that is executed when it is applied.
+
+An advice can be applied at a defined \emph{pointcut}. A pointcut picks out one
+or more \emph{join points}. A join point is a well-defined point in the
+execution of a program. It can occur when calling a method defined for a
+particular class, when calling all methods with the same name,
+accessing/assigning to a particular field of a given class and so on. An advice
+can be declared to run both before, after returning from a pointcut, when there
+is thrown an exception in the pointcut or after the pointcut either returns or
+throws an exception. In addition to picking out join points, a pointcut can
+also bind variables from its context, so they can be accessed in the body of an
+advice. An example of a pointcut and an advice is found in
+\myref{lst:aspectjExample}.
+
+\begin{listing}[h]
+\begin{minted}{java}
+pointcut methodAnalyze(
+ SearchBasedExtractAndMoveMethodAnalyzer analyzer) :
+ call(* SearchBasedExtractAndMoveMethodAnalyzer.analyze())
+ && target(analyzer);
+
+after(SearchBasedExtractAndMoveMethodAnalyzer analyzer) :
+ methodAnalyze(analyzer) {
+ statistics.methodCount++;
+ debugPrintMethodAnalysisProgress(analyzer.method);
+}
+\end{minted}
+\caption{An example of a pointcut named \method{methodAnalyze},
+and an advice defined to be applied after it has occurred.}
+\label{lst:aspectjExample}
+\end{listing}
+
+\subsection{The Statistics class}
+The statistics aspect stores statistical information in an object of type
+\type{Statistics}. As of now, the aspect needs to be initialized at the point in
+time where it is desired that it starts its data gathering. At any point in time
+the statistics aspect can be queried for a snapshot of the current statistics.
+
+The \type{Statistics} class also include functionality for generating a report
+of its gathered statistics. The report can be given either as a string or it can
+be written to a file.
+
+\subsection{Advices}
+The statistics aspect contains advices for gathering statistical data from
+different parts of the benchmarking process. It captures statistics from both
+the analysis part and the execution part of the composite \ExtractAndMoveMethod
+refactoring.
+
+For the analysis part, there are advices to count the number of text selections
+analyzed and the number of methods, types, compilation units and packages
+analyzed. There are also advices that counts for how many of the methods there
+is found a selection that is a candidate for the refactoring, and for how many
+ethods there is not.
+
+There exists advices for counting both the successful and unsuccessful
+executions of all the refactorings. Both for the \ExtractMethod and \MoveMethod
+refactorings in isolation, as well as for the combination of them.
+
+\section{Optimizations}
+When looking for optimizations to make for the benchmarking process, I used the
+\emph{VisualVM}\footnote{\url{http://visualvm.java.net/}} for the Java Virtual
+Machine to both profile the application and also to make memory dumps of its
+heap.
+
+\subsection{Caching}
+When profiling the benchmark process before making any optimizations, it early
+became apparent that the parsing of source code was a place to direct attention
+towards. This discovery was done when only \emph{analyzing} source code, before
+trying to do any \emph{manipulation} of it. Caching of the parsed ASTs seemed
+like the best way to save some time, as expected. With only a simple cache of
+the most recently used AST, the analysis time was speeded up by a factor of
+around
+20. This number depends a little upon which type of system the analysis was
+run.
+
+The caching is managed by a cache manager, that now, by default, utilizes the
+not so well known feature of Java called a \emph{soft reference}. Soft
+references are best explained in the context of weak references. A \emph{weak
+reference} is a reference to an object instance that is only guaranteed to
+persist as long as there is a \emph{strong reference} or a soft reference
+referring the same object. If no such reference is found, its referred object is
+garbage collected. A strong reference is basically the same as a regular Java
+reference. A soft reference has the same guarantees as a week reference when it
+comes to its relation to strong references, but it is not necessarily garbage
+collected whenever there exists no strong references to it. A soft reference
+\emph{may} reside in memory as long as the JVM has enough free memory in the
+heap. A soft reference will therefore usually perform better than a weak
+reference when used for simple caching and similar tasks. The way to use a
+soft/weak reference is to as it for its referent. The return value then has to
+be tested to check that it is not \var{null}. For the basic usage of soft
+references, see \myref{lst:softReferenceExample}. For a more thorough
+explanation of weak references in general, see\citing{weakRef2006}.
+
+\begin{listing}[h]
+\begin{minted}{java}
+// Strong reference
+Object strongRef = new Object();
+
+// Soft reference
+SoftReference<Object> softRef =
+ new SoftReference<Object>(new Object());
+
+// Using the soft reference
+Object obj = softRef.get();
+if (obj != null) {
+ // Use object here
+}
+\end{minted}
+\caption{Showing the basic usage of soft references. Weak references is used the
+ same way. {\footnotesize (The references are part of the \code{java.lang.ref}
+package.)}}
+\label{lst:softReferenceExample}
+\end{listing}
+
+The cache based on soft references has no limit for how many ASTs it caches. It
+is generally not advisable to keep references to ASTs for prolonged periods of
+time, since they are expensive structures to hold on to. For regular plugin
+development, Eclipse recommends not creating more than one AST at a time to
+limit memory consumption. Since the benchmarking has nothing to do with user
+experience, and throughput is everything, these advices are intentionally
+ignored. This means that during the benchmarking process, the target Eclipse
+application may very well work close to its memory limit for the heap space for
+long periods during the benchmark.
+
+\subsection{Memento}
+
\chapter{Eclipse Bugs Found}
\todoin{Add other things and change headline?}
git://git.uio.no / ifi-stolz-refaktor.git / blobdiff