\section{Introduction}

On these days, Android from Google is the mobile platform present on the majority of the smartphones used in the world~\cite{mobileshare}.
Traditionally, those applications were developed using Java programming language.
However, in 2017, Google adopted Kotlin, a new programming  language, as official language for developing Android applications.
Thus, since then, Android developers have the possibility (and official support from Google) of developing Android apps using:
\begin{inparaenum}[\it a)]
\item Java, 
\item  Kotlin,  or 
\item both languages.
\end{inparaenum}

Kotlin is a programming language that combines object-oriented and functional features, some of them not present in Java or not available for Android development.\footnote{https://kotlinlang.org/docs/reference/comparison-to-java.html}
Kotlin is compiled to Java byte-code, which means that 
\begin{inparaenum}[\it a)]
 \item an application written in Kotlin can be executed on the Java virtual machine, and
\item Kotlin is fully interoperable with Java, i.e. Kotlin code can invoke programs written in Java and vice-versa.
\end{inparaenum}

The adoption of Kotlin as official development language for building Android applications has produced three main scenarios.
Android developers can:  
\begin{inparaenum}[\it 1)]
\item start writing an application from scratch in Kotlin,
\item evolve their Android apps initially written in Java by adding Kotlin code and maintaining the existing Java code,
\item totally migrate an application, initially written in Java, to Kotlin.
\end{inparaenum}
Recently, Coppola et al. presented the first characterization of the migration from Java to Kotlin of Android apps \cite{Coppola:2019:CTK}.
They studied the evolution of such apps using metrics based on the amount of Kotlin and Java code (LOC) and numbers of files. 
Their results show that the transition from Java to Kotlin was in general
\begin{inparaenum}[\it a)]
\item  fast (quick transition between languages), and
\item unidirectional (the ratio of Kotlin over total code was often increasing during their evolution).
\end{inparaenum}

In this paper, we go one step further on the characterization of the migration of Android apps to Kotlin.
We aim to know \emph{Why}  and \emph{How} Android developers migrated their applications.
This paper presents the initial responses to those questions.


To answer \emph{How} and \emph{Why} developers migrate their Android apps, we carried out two experiments.
Firstly, we executed code analysis to identify, analyze and classify \emph{commits} that migrate code.
Our research is based on a tool we built, named {\bf{MigA}}, which analyzes the evolution of migrated apps.
To our knowledge, no previous work has studied in detail the characteristics of the commits that migrate code.

Secondly, we interviewed 78{} developers that have already migrated Java code from their Android applications. We initially asked them \emph{Why} (for which reasons) they migrated code.
This survey complements that one done by Oliveira et al. \cite{OliveiraSANER20p206} which interviewed 7 developers to gain knowledge about the adoption of Kotlin on mobile development.
In this work, we go one step further: we particularly focus on \emph{migrations} and, via those interviews, we could capture the migration experiences of 78{} developers.

Our research is important.
We believe that, since the official adoption of Kotlin, Android development has begun a new era.
As Kotlin is a relative new programming language (v1.0 released on 2016) and as it was recently adopted as official programming language for Android,
we consider that understanding \emph{how} and \emph{why} developers migrate Android apps from Java to Kotlin is essential for 
\begin{inparaenum}[\it a)]
\item discovering the difficulties developers have, and \item helping and supporting them with documentation and tools during the development and migration activities.
\end{inparaenum}


\begin{comment}
In this paper we present a framework called {\bf{MigA}}{} designed for studying the evolution of applications that have been written in two or more languages.
{\bf{MigA}}{} presents analyzers for studying the evolution of Java and Kotlin code and for detecting commits that migrate code.
Moreover, due to the architecture of {\bf{MigA}}, researchers can reuse the analyzers already provided, extend them or create new ones. \todo{for new experiments that analyze more in detail the migration of applications.}

\new{The results returned by Miga allows us to identify the developers that have migrated Java to Kotlin.
We contacted them to ask about their experience on migrating code.
}
\end{comment}

\begin{comment}
The goals of this paper are:
First to study the amount of Java and Kotlin code present in Android apps and the variation along the time.
\new{To know what  motivates developers to migrate from Java to Kotlin. }
Then, to study how developers migrated apps initially written in Java to Kotlin.
\new{To discuss about the experience of developers when migrated}
Finally, to study the evolution of applications that having both Java and Kotlin code in the latest version.
In this paper we use {\bf{MigA}}{} for studying the evolution of 374 open-source Android applications that contain, at least, one line of code written in Kotlin and, eventually, Java code.
\end{comment}



\newcommand{\rqappsmigrated}{{RQ 1: How many Android applications have been fully migrated to Kotlin?
}}


\newcommand{\rqmigrationdone}{{
RQ 2: How did developers migrate from Java to Kotlin?
}}

\newcommand{\rqwhymig}{{RQ 3: 
Why (for which reasons) have developers migrated their Android applications from Java to Kotlin?
}}


\newcommand{{RQ 4: Are the mobile apps which latest versions have both Java and Kotlin in  process of being migrated?}}{{RQ 4: Are the mobile apps which latest versions have both Java and Kotlin in  process of being migrated?}}




\newcommand{\rqadvise}{{RQ 5: What are the main advises to Android developers based on the interviews?}} 


The research questions that guide our research are:
\begin{enumerate}

\item{\it{ \rqappsmigrated{} }}

We automatically analyze a dataset of Android apps having Kotlin code to filter those that have been fully migrated from Java to Kotlin.

\finding{From 374 Android apps analyzed, 86 apps have been completely migrated from Java to Kotlin.}



\item  {\it{\rqmigrationdone}}

We analyze the history (code repository) of Android applications that have been fully migrated.
We compute for each app the portion of the history corresponding to the migration.
Then, we  retrieve the commits that carry out the code migration.
From them, we are able to identify the developers that have written the migrations.

\finding{
The  36\%  of  the  migrated  applications  were  completely migrated in one single commit.
Those apps do not have any version that contains both Java and Kotlin.
}





\item{\it{\rqwhymig}}

We ask developers that have migrated code the main reasons of migrating their Android applications.


\finding{We present the ten main reasons we extracted from the interviews, those include: 
\begin{inparaenum}[\it a)]
\item to avoid limitations of Java versions, 
\item to produce safer code, 
\item to use a modern program language with new features, and 
\item to follow Google's direction.
\end{inparaenum}
}

\item {\it{ {RQ 4: Are the mobile apps which latest versions have both Java and Kotlin in  process of being migrated?}}}

We study the apps apps having both languages, but not completely migrated, to determine whether they are in the process of being  migrated from Java to Kotlin.
We also contact those developers to know the reasons about those application have not been fully migrated yet.

\finding{For, at least, the 63\% of the  214 apps not completely migrated, the amount and proportion of Kotlin code increase along the time.
The interviews with developers show that they did not finish the migration because of:
\begin{inparaenum}[\it a)]
\item only Java code that needs to be modified is migrated, 
\item only new code is written in Kotlin,
\item lack of time to complete the migration.
\end{inparaenum}
}

\item{\it{\rqadvise}}

We present recurrent episodes and advises that developers mentioned us during the interviews.

\finding{We found that:
\begin{inparaenum}[\it a)]
\item Developers used the auto-converter tool for migrating code, however, the converted code often needs to be manually modified;
\item Coroutines simplify the implementation of concurrency in Android;
\item Kotlin code is easier to read and maintain according to the majority of the interviewed developers.
\end{inparaenum}
}



\end{enumerate}

\begin{comment}
The main findings of this paper are:
\begin{enumerate}
\item From 374 apps, 86 apps have been completely migrated from Java to Kotlin,
\item the majority of commits from apps having both Java and Kotlin affect a single program language, whereas few commits affect both language.
\item The majority of those apps (53) have been migrated in less than 10 consecutive commits.
\item 214 apps have in the latest version both Java and Kotlin,
\item For, at least, the 63\% of those 214 apps, the amount and proportion of Kotlin code increase along the time.
\end{enumerate}
\end{comment}


The contributions of this paper are:
\begin{enumerate}[]
\item A framework named {\bf{MigA}}{} for a) studying the evolution of applications having two or more programming languages and b) detecting commits that migrate code.
\item An implementation of {\bf{MigA}}{} tailored for studying apps written in Java and Kotlin.
\item The characterization of the evolution and  migration  of Android  application initially written in Java, based on commit analysis and interviews with developers.
\item An enumeration of the main reasons why Android developers migrated to Kotlin.
This could encourage Android developers to migrate to Kotlin.
\item A list of episodes and advises extracted from the interviews with developers which can be used by both Android developers (e.g., to decide whether to migrate to Kotlin or not), and by researchers (e.g., to propose solutions that overcome the current problematic developers face).
\item A dataset of commits that migrated code detected by {\bf{MigA}}. Researcher can use it for further studies on the migration activity of Android application
\end{enumerate}

The paper continues as follow.
Section \ref{sec:methodology} presents the methodology.
Section \ref{sec:evaluation} presents the responses of the research questions.
Section \ref{sec:tov} discusses the threats to validity.
Section \ref{sec:discussion} presents the discussion and future work. 
Section \ref{sec:rw} presents the related work.
Section \ref{sec:conclusion} concludes the paper.




\section{Methodology}
\label{sec:methodology}

To respond the research questions, in this section we first present a tool, named {\bf{MigA}}{}, that analyzes repositories of applications.
Then, we explain how we used it to respond the research questions.
Finally, we present the methodology we applied to carry out a survey which consisted on interviews with developers that migrated code to Kotlin.


\subsection{Methodology applied for analyzing commits}

To detect commits that migrate code, we build a tool called {\bf{MigA}}{}.
It allows researchers to study the evolution of software applications i.e., the changes done over an application along its history.
In particular, {\bf{MigA}}{} focuses on analyzing applications that, during their evolution, have been migrated to one programming language to another (or others).
In this section we present {\bf{MigA}}{} and we describe how we process its output for responding the research questions.
\label{sec:migaframework}

\subsubsection
{Architecture and Implementation of {\bf{MigA}}{}}
\label{sec:architecture}


{\bf{MigA}}{} is built on top of Coming \cite{coming2019}, a framework for studying the evolution of applications.
{\bf{MigA}}{} frameworks takes as input the location of a GIT repository on disk. 
It navigates each commit in chronological order, starting from the oldest one.
{\bf{MigA}}{} extends Coming with new analyzers for studying the migration of applications. 
In particular, {\bf{MigA}}{}: 
\begin{inparaenum}[\it a)]
\item {Analyzes added, removed and modified files from a commit},
\item {Analyzes commit messages},
\item {Compute lines of code of a version associated to a commit},
\item {Creates  Java ASTs for the Java files affected by a commit},
\item {Creates  Kotlin ASTs for the Kotlin files affected by a commit},
\item {Computes the differences introduced by a commit at the AST level},
\item {Detects commits that migrate code}.
As output, {\bf{MigA}}{} generates a JSON file containing, for each commit, the information produced by each aforementioned analyzers.
\end{inparaenum}


\subsubsection{Lines of code per language}
For responding the first research question (RQ1), we analyze the output of {\bf{MigA}}{} containing  per each commits $C$:
\begin{inparaenum}[\it a)]
\item the lines of source code (sLOC), and 
\item number of files 
\end{inparaenum} for each program language used on the version associated to $C$.


\subsubsection{Migration interval}
\label{sec:method:migrationinterval}

For responding the second research question (RQ2), 
we detect from the {\bf{MigA}}'s output, for each application:
\begin{inparaenum}[\it a)]
\item the first commit that uses Kotlin code, and
\item the last that  uses Java code.
\end{inparaenum} 
We call \emph{migration interval} to the portion of the application's history between those two commits.
The \emph{migration interval length} of a migrated application is the number of commits that happen between the two previously retrieved commits.

We further compute the \emph{proportion} of the migration interval w.r.t all the commits from the history of one application by dividing the length of the interval by the total number of commits.


\subsubsection{Detecting commits that migrate code}
\label{sec:commit_migration}

Moreover, also for responding research question 2, we implemented on {\bf{MigA}}{} the detection of three types of commits that migrate code.
Those are:

\paragraph{File-level Migration}
\label{sec:file_migration}
{\bf{MigA}}{} is able to detect \emph{File-level Migrations} commits.
They are commits that migrate code
by removing one Java file and adding a new Kotlin file.
{\bf{MigA}}{} checks that  the names of those files are the same (excluding the file extension).

\paragraph{Finer-grained code level migration}
\label{sec:fine_grained_migration}
\label{sec:method_migration}

{\bf{MigA}}{} is able to detect  commits that migrate code at a fine-grained level, which we named \emph{code-level migration}.
This type of migration happens when a developer migrates code by updating two (or more) existing files written in two different languages: 
Java code is removed and Kotlin code is added.
The current implementation of  {\bf{MigA}}{}  is able of detecting on \emph{methods} level migrations.\footnote{
Even it is not covered in this paper, {\bf{MigA}}{} can detect other code-level migrations, such as properties or blocks.}

For detecting method-level migration commits, {\bf{MigA}}{} applies the following steps on each commit:
\begin{inparaenum}[\it a)]
\item verifies that 1 or more Java files \emph{and} 1 or more Kotlin files are updated by a commit $c$;
\item for each updated Java or Kotlin file $f$, {\bf{MigA}}{} creates an AST (Abstract Syntax Tree) from $f$ and another from the previous version of $f$, i.e. $f_p$;
\item {\bf{MigA}}{} computes the differences between the ASTs obtained from $f$ and  $f_p$, using GumTree algorithm \cite{Falleri:2014:FAS}. The output is a list of AST changes, where each change is an operation (Insert, Remove, Update and Move) done over an AST node;
\item {\bf{MigA}}{} finds for INSERT operations that affect \emph{methods} in the $diff$ obtained from comparing Kotlin files, and DELETE operations that also affect methods in the other $diff$ obtained from comparing Java files.\footnote{By default, {\bf{MigA}}{} does not match the method names, even it is possible to apply string matching heuristics.}
\end{inparaenum}

\paragraph{Update-Insert Migration}
\label{sec:update_insert_migration}
{\bf{MigA}}{} can detect commits that removes a piece of code (e.g., method) from a file written in Java and, at the same time, adds a new file written written in Kotlin.
The implementation of this detector is based on the two previously described cases.

\paragraph{Other types of migrations}
Beyond those three types of commits that migrate code, there could be other that also migrate code.
We leave the discover and characterization of such types, and the detection of commit corresponding to the emerging types for future work. In Section \ref{sec:discussion} we discuss some future directions for discovering them.


\begin{comment}
\subsubsection{Commit composition}
\label{sec:method:proportion}
\todo{re-do?}
Moreover, in RQ 1, we study the composition of commits according to the program languages they affect.
The classify commits in 4 types \todo{weird sentence}: 
\begin{inparaenum}[\it 1)]
\item Pure-Java (commits that affect Java code but not Kotlin),
\item Pure-Kotlin (commits that affect Kotlin code but not Java),
\item Mix (commits that affects both Java and Kotlin code),
\item Other (commits that do not affect nether Java nor Kotlin code, e.g., XML files).
\end{inparaenum}
\todo{To me moved to Migration study and to compute it after Kotlin is introduced}
\end{comment}



\subsubsection{Amount and proportion of Kotlin code}
\label{sec:method:amountkotlin}

For responding the first  and fourth research questions, 
{\bf{MigA}}{} computes, for each application $a$ and for each commit $c$, the number of Java and Kotlin lines of codes (sLOC) of the version of $a$ given by $c$.
It also computes the proportion of Kotlin code by dividing the sLOC of Kotlin per the total sLOC (i.e., Java sLOC + Kotlin sLOC).
Then, for each application, 
we compute the variation of both amount of sLOC and proportion between the latest commit done and an older commit.
In particular, we consider two older commits:
\begin{inparaenum}[\it 1)]
\item the \emph{first commit} that introduces Kotlin,  and
\item a ``\emph{recent commit}'', which corresponds to the commit done just before the latest 10\% of all commits.
\end{inparaenum}
For example, if one application has 110 commits and Kotlin was introduced in the commit \#10, we compare the amount/proportion of Kotlin code between the commit \#110 (latest) and: 
\begin{inparaenum}[\it a)]
\item the \emph{first commit}: \#10 (first Kotlin commit),
\item  the \emph{recent commit}: \#100 (beginning of the last 10\%  from all the Kotlin commits).
\end{inparaenum}


\subsection{Methodology applied for executing the survey}
\label{sec:methodology:survey}

For responding research questions 3, 4 and 5, we conducted a survey with developers.
In this section, we detail the characteristics and initial results of this survey.

\subsubsection{Survey purpose}

We carry out a survey with the main goal of collecting information about the migration of Java code to Kotlin in the context of Android development.
Our survey is explanatory~\cite{experimentationSE2012}: we try to explain why developers migrated their applications. 
The survey follows the format of interviews via email and aims at gathering both qualitative and quantitative data.

We initially asked developers a single question via email:
\quotes{Why did you migrate code from Java to Kotlin?}.
Then, once we received an answer from them, we further asked new questions according to their replies.
For example: 
\begin{inparaenum}[\it a)]
\item \quotes{Did you use the auto-converter code tool provided by the IDE?},
\item \quotes{Which was the criterion (if any) to choose those classes to migrate?},
\item \quotes{Your project still has Java code, Why has it not been completely migrated yet?}.
\end{inparaenum}

We choose this format of exploratory survey, composed of an initial question and followed by a loosely structured questionnaire, to follow the recommendations given by~\cite{experimentationSE2012}, which indicates that letting interviewers handle the questionnaire instead of the respondents themselves offers a number of advantage, such as observing the answers and ask questions according to the observation. 

\subsubsection{Survey setup}

{\bf{MigA}}{} framework is able to return \emph{all} commits that migrate Java code to Kotlin from our dataset of Android applications (Section \ref{sec:dataset}).
From each commit, we retrieved the name 
and the email address of the developer that made the commit.
That information is the repository history (GIT).
Then, we sent to each developer that made a migration a personalised email that mentioned that we have analyzed the code of her/his application (mentioning the app name) and we have detected that she/he has write a commit (or several) that migrated code from Java to Kotlin. 

\subsection{Survey results}

We could successfully send, in total, 249 emails.\footnote{Some emails could not be successfully delivered (e.g., those from development companies which employers do not work there any more).}
We got the response from 78{} developers, all them from different projects.
This means that $\sim$30\% of developers that migrated Java code to Kotlin in applications from the dataset we study (Section \ref{sec:dataset}) have participated in our survey.
Those interviewed developers are from, at least, 17 countries.
Note that not all participants replied \emph{all} the questions we asked them.
Along this paper we \emph{literally} present answers from developers, without doing any kind of modification (e.g., typos or grammar issues).

Once we collected all answers, 
we detailed analyzed each interview (i.e., a thread of emails with answers and responses) to collect all valuable information for responding research questions 3 (why they migrated), 4 (why not fully migrated) and 5 (advises).


\subsection{Dataset of Android Applications studied}
\label{sec:dataset}
Given Google has officially adopted Kotlin as programming language for Android, 
our goal is to study the migration from Java to Kotlin of Android applications.
For this reason, we analyze Android applications from the FAMAZOA dataset \cite{GoisMateus2019}, which contains 374 Android  with at least one commit done in Kotlin.
FAMAZOA dataset was built by combining open-source applications mined from different sources such as F-Droid\footnote{F-Droid: dataset of open-source Android applications \url{https://f-droid.org}} repository and Android Time Machine \cite{Geiger2018:data}.


\section{Experiment Results}
\label{sec:evaluation}

\subsection{\rqappsmigrated{}}

To respond this research question, we first analyze the languages used:
\begin{inparaenum}[\it a)]
\item at the beginning of the development, 
\item during the development of an application, and finally
\item  in the last commit.
\end{inparaenum}
The fully migrated applications detected in this research question, as well those not fully migrated, will be studied in the next research questions.

\subsubsection{Initial Programming Language}
\label{sec:res:initiallang}


We analyze 374 Android applications from {FAMAZOA}{} dataset.
By construction, all applications from there have, at least, one file with Kotlin code and, eventually, one file with Java code.

Table \ref{tab:lang} presents the results. 
In total, 65  apps were initially written only using Kotlin code.\footnote{\label{lab:javatest}
From the 65 apps, 21 have Java code corresponding to test cases  named `ExampleUnitTest.java' and `ApplicationTest.java' automatically generated by IDEs such as Android Studio when a project is created. Those tests have not been modified after the creation. For this reason, we ignore them.}
From the remaining 309 apps, 269 started being developed just using Java code (i.e., Java code was used before  Kotlin code),
and 40 apps have been developed using both Kotlin and Java since the first version pushed to their respective version control systems.


\begin{table}[t]
\centering
 \begin{tabular}{|l||  r | r |   } 
 \hline
Language& \multicolumn{2}{c|}{Number  Applications having:} \\
\cline{2-3}
& Initial  version  & Latest version  \\
\hline
Java &269&4\\
\hline
Kotlin &65&156\\
\hline
Both &40&214\\
\hline
\hline
Total& \multicolumn{2}{c|}{374}\\
 \hline
 \end{tabular}
\caption{Number of apps having Java and Kotlin version in their first and last versions.}
\label{tab:lang}
\end{table}

\subsubsection{Languages used along the history}
\label{sec:res:langusedhistory}

Our dataset has in total 60 apps (16\%) completely written in Kotlin along their history.\footnote{
Between the 60 apps, there are 16 that introduce (but not evolve) the automatically generated tests mentioned in footnote \ref{lab:javatest}.}
The rest, 314 apps  (84\%), evolves by adding and modifying Kotlin and Java code (at the same or different time).
\begin{comment}

In total, 44 apps have been developed using just Kotlin code along their complete history, without having a single line of Java code. 
Moreover, we found that 16 additional apps that were written in Kotlin and have one or more commits including the mentioned  test files automatically written in Java (Section \ref{sec:res:initiallang}) and no more Java code in any commit from their history.\footnote{In Section \ref{sec:res:initiallang} we report 21 apps that introduce automated generated tests in their first commits, and in Section \ref{sec:res:langusedhistory}  we report 16 apps that  introduce those tests in any part of their history, not only at the beginning. This means that 5 apps (21 - 16) add one or more Java files (different from those testing files) during their evolution.} 
Consequently, by ignoring such files and considering those apps as Pure Kotlin, our dataset has in total 60 (16\%) apps completely written in Kotlin.
The rest, 314 apps  (84\%) evolve by adding and modifying Kotlin and Java code (at the same or different time).
\end{comment}

\newcommand{{Migrated-Apps-j2k}}{{Migrated-Apps-j2k}}
\newcommand{{Mix-Java-Kotlin Apps}}{{Mix-Java-Kotlin Apps}}

\subsubsection{Languages used in the last version}
\label{sec:res:langusedlastversion}

We now focus on the remaining 314 apps (i.e., 374 - 60) which have Java and, eventually, Kotlin.
214 apps have both Kotlin and Java in the latest commit. 
Those apps form the set named \emph{{Mix-Java-Kotlin Apps}{}}.
Now, let's inspect the remaining 100 apps (314 - 214).
In this paper we are particularly interested in 86 of them, which have been initially written exclusively on Java and \emph{fully} migrated to Kotlin. Those apps from the set named \emph{{Migrated-Apps-j2k}}.

We now describe the other 14 apps (100 - 86), which we do not study in this paper.
First, there are 10 apps that have  initial commits written in Koltin,  and Java code was introduced and subsequently removed.
\begin{comment}
\begin{inparaenum}[\it a)]
\item  5 apps have been initially written using both Kotlin and Java.
\item 5 apps have only Kotlin code in their initial version, and Java code was introduced and subsequently removed.
\end{inparaenum}
\end{comment}
Then, the remaining 4 applications had Kotlin code but it was removed, remaining only Java code in their latest versions.
\begin{comment}
For one of them, their developers have started written it in Kotlin and, at the middle of its history, the developers completely migrated to Java.
The others 3 app have been initially developed in Java, then the developers added some functionalities on Kotlin, which were finally removed, remaining, again, only Java code.
\end{comment}
We interviewed one developer that introduced Kotlin on one of those apps.
He told us: 
\quotes{I tried to migrate [...] but other contributors just find it complicated to incorporate two languages style in a single project and, eventually reverted the project to some time before}.


\begin{tcolorbox}
86 Android applications (out of 314) were completely migrated from Java to Kotlin.
Then, 
214 apps were initially written in Java and they have been partially migrated.
\end{tcolorbox}

\begin{comment}
\subsubsection{Moment of First use of Kotlin}
\label{sec:res:kotlinfirstintroduction}


\begin{figure}[t]
\centering
 \includegraphics[scale=0.5]{histogram_introduction_kotlin_percentage_374.pdf}
  \caption{Distribution of Introduction moments of  Kotlin code for all applications (374). Zero value means the beginning of the history, 1 means the end. Consequently, the histogram shows that  more than 110 apps have an introduction moment near to zero, which means that Kotlin is used for a first time at the beginning of the project history.}
 \label{fig:hist_kotlin_intro_all}
\end{figure}

Histogram \ref{fig:hist_kotlin_intro_all} shows the distribution of the \emph{Introduction moment}  of Kotlin code (as explained in Section \ref{sec:method:intromoment}).
The mean and the median are both ~0.40, which means that Kotlin is introduced, on average, after the first 40 \% of the commits of the application.
We found that 62  apps have a later introduction greater than 0.8, which mean that Kotlin was introduced at the end of the application history. 

\end{comment}









\subsection{\rqmigrationdone}
\label{sec:res:migration}

We now focus on the 86 apps from set  \emph{{Migrated-Apps-j2k}} that started being developed using Java and were subsequently completely migrated to Kotlin.

To respond this research question, 
we do two experiments.
First, we study the \emph{migration intervals} to characterize the duration of the migrations in terms of commits.
Then, we analyze commits inside the migration interval to detect those that could have migrated code. 

\subsubsection{Migration Intervals}

Histogram \ref{fig:kotlin_migration_duration} shows the distribution of the length the \emph{migration intervals}\footnote{For ease of reading, we removed from the Histogram \ref{fig:kotlin_migration_duration} two \emph{outliers}: Rocket.Chat.Android which  interval has 1988 commits  and Voice with 2018.}
and Histogram \ref{fig:kotlin_migration_duration_normalized} shows the distribution of  their lengths normalized by the total number of commits from the application.
This normalization has as goal to observe the duration of the migration w.r.t the complete history of one application.
From them, we identified two main migration strategies. Those are:

\begin{figure}[t]
\captionsetup{justification=centering}
    \centering
 \begin{subfigure}[b]{0.30\textwidth
        \includegraphics[width=\textwidth]{lines_Simplebitcoinwidget.pdf}
       
        \caption{SBitcoinWidget: $mi$ = 1 commit}
        \label{fig:linesSimplebitcoinwidget}
    \end{subfigure}
    \begin{subfigure}[b]{0.30\textwidth}
         \includegraphics[width=\textwidth]{lines_Localstorage.pdf}
           \caption{Localstorage: $mi$ = 4 commits}
      \label{fig:linesLocalstorage}
    \end{subfigure}
    \begin{comment}
     \begin{subfigure}[b]{0.30\textwidth}
 \includegraphics[width=\textwidth]{lines_Uncmorfi.pdf}
  \caption{UNCmorfi: $mi$ =  28   commits \todo{to remove it}}
 \label{fig:lines-UNCmorfi}
    \end{subfigure} 
      \end{comment}
     \begin{subfigure}[b]{0.30\textwidth}
    \includegraphics[width=\textwidth]{lines_Red.pdf}
        \caption{Red: $mi$ = 188   commits}
    \label{fig:linesRed}
    \end{subfigure}
    \caption{Evolution of Kotlin and Java code for 3 applications having  migration intervals  ($mi$) with different lengths. Axis X corresponds to commits, axis Y to sLOC.}
    \label{fig:examples_mig_interval}
\end{figure}

\begin{figure}[t]

\begin{subfigure}{0.48\linewidth}
 \includegraphics[scale=0.3]{histogram_range_84.pdf}
  \caption{Lengths of Migration Intervals (in number of commits)}
 \label{fig:kotlin_migration_duration}
\end{subfigure}
\hfil
\begin{subfigure}{0.48\linewidth}
 \includegraphics[scale=0.3]{histogram_range_Percentage_84.pdf}
  \caption{Lengths of Migration Intervals divided by number of commits.}
 \label{fig:kotlin_migration_duration_normalized}
\end{subfigure}
\caption{Distribution of the migration interval  lengths corresponding to the 86 apps from set  \emph{{Migrated-Apps-j2k}}.}
\label{fig:kotlin_migration_duration_main}
\end{figure}



\paragraph{One-Step migration}

In total, 31  projects (out of 86 apps from \emph{{Migrated-Apps-j2k}}, that is, the 36\%)  have migration interval lengths equals to 1, which means that they were migrated in \emph{exactly} one commit.
Those commits remove all Java files and introduce the Kotlin code. 
One of those applications is `SimpleBitcoinWidget', which code  evolution is presented in Figure \ref{fig:linesSimplebitcoinwidget}. 

Eight developers that replied to our interview request had migrated their apps in one single commits. 
Half of them confirmed us that they migrated the code using the converter tool provided by the IDE Android Studio.




\begin{comment}
Additionally, we found  two applications which migration intervals are \emph{negative}.
However, the migration were done quite similarly to the previous 29 apps: 
one commit first removes all Java code, and then, in the next commit, the Kotlin code is introduced.
\end{comment}

\begin{tcolorbox}
The 36\% of the migrated applications were completely migrated  in one step (i.e one single commit).
\end{tcolorbox}


\paragraph{Staggered migration}

For the rest of the 55 applications (out of 86,  i.e., that is the 64\%), their \emph{migration interval lengths} are greater than one commit.
There, the migrations were gradually done: some version have both Java and Kotlin code.
For example, LocalStorage and Red apps, which code evolution trends are presented in Figures \ref{fig:linesLocalstorage}  and \ref{fig:linesRed}, present intervals with length 4 and 188 commits, respectively.
Histogram \ref{fig:kotlin_migration_duration} shows the distribution of the migration intervals for all migrated applications.
Even discarding those 31 migrated in one-step, we observe that most apps were fully migrated in intervals smaller than 50 commits.
However, there are apps with larger intervals. 
For example, that one from SimpleGalery has 266 commits.

We then normalized the intervals. 
As shown by the Histogram \ref{fig:kotlin_migration_duration_normalized}, for most of the apps, the normalized interval's lengths are near to zero, which means that their migrations happened during a short period during their history. 
Coming back to SimpleGalery app, even its interval is one of the largest we found, it's relative small compared to its large complete history: the proportion is 0.093.



\begin{comment}
Figure \ref{fig:scatter_range} shows the relation between the \emph{migration interval}  and that normalized value.
At the left-bottom of the plot  where both proportion of migration and length trend to zero,  are located most of the applications, including the 29 mentioned applications with interval equals to zero. 
This means that migrations happens in few commits consecutive commits inside a large history in terms of number of commits. 
There are some application with short migration intervals, but they covers a larger portion of history, e.g., `Unstoppable' app has 6 commits in its migration interval but the total number of commit is 23, thus the proportion is 0.26.
On the contrary, other projects, such as  SimpleGalery, have larger intervals but the its proportion is lower (for SimpleGalery those values are  266 and 0.093, resp.).


 \begin{figure}[t]
\centering
    \includegraphics[width=0.75\textwidth]{scatter_range_84.pdf}
       \caption{Length (axis X) and proportion (axis Y) of the Migration interval of each migrated application.}
    \label{fig:scatter_range}
 \end{figure}

\end{comment}


\begin{tcolorbox}
Most of the  apps were completely migrated from Java to Kotlin in few commits and the migration interval represents less than the 10\% of the complete history of those applications.
\end{tcolorbox}






\begin{comment}
A particular case is Rocket.Chat.Android, which interval is an \emph{outlier}. 
Their developers stared developing that application in Java, arriving to version  with 20K lines of Java code. 
Later, In the commit, they introduced Kotlin language and during X commits the amount of Kotlin commit moderaly increases, remaining the amount of Java code almost constant. However, in one particular commit\footnote{5509fb5b16fea584f9dbdd985834b9ec9efcf922 } both Java and Kotlin are removed, and the next step the app is rewritten from scracht using mainly Kotlin. 
Few Java code is introduced in this new version, which is gradually removed until the app only contain Kotlin code.
\end{comment}


\subsubsection{Detection of commits that Migrate Java to Kotlin}
\label{sec:res:migtypes}

We now focus on the detection of commits that migrates code from the 86 completely migrated apps.
We aim to detect the three types of migration commits presented in  Section \ref{sec:commit_migration}. 

\paragraph{Migrations of Files}
\label{sec:res:migrationfiles}

\begin{figure}[t]
\begin{subfigure}{0.45\linewidth
 \includegraphics[scale=0.30]{histogram_migrationCommits_84.pdf}
  \caption{Distribution of  the number of File-migration commits.}
 \label{fig:kotlin_migration_commits}
\end{subfigure}
\hfil
\begin{subfigure}{0.45\linewidth}
 \includegraphics[scale=0.30]{histogram_migrationCommits_proportion_84.pdf}
  \caption{Distribution of Proportion of File-migration commits. 
  }
 \label{fig:kotlin_migration_commits_proportion}
\end{subfigure}
\caption{Distribution of the number and proportion of  commits that migrate Files from Java to Kotlin per application.
}
 \label{fig:kotlin_migration_commits_all}
\end{figure}


The histogram \ref{fig:kotlin_migration_commits}  shows the distribution of the number of commits that migrate Files (Section \ref{sec:file_migration}) from the set  \emph{{Migrated-Apps-j2k}} (in total 86 apps).
It shows that the majority of the applications (i.e.~$>$50) have few commits that migrate files: from 1 to 5. 
On average the number of migration commits is  8.25  and the median is  2.

The histogram  \ref{fig:kotlin_migration_commits_proportion} shows the proportion of File migration commits divided by the lengths of the migration intervals.
In total, for 35 apps the proportion is 1 (the bar at the rightmost), meaning that \emph{every} commit in the migration interval migrates, at least, one file from Java to Kotlin.
\begin{comment}
\end{comment}
\begin{comment}
Another app, named UNCmorfi which code evolution is presented in Figure \ref{fig:lines-UNCmorfi}, has an interval with 28 commits,  27  of them commits migrate a single file. 
The proportion of migration commits is  0.96 (96\%,  27/28). 
Note that those commits eventually also modify already written code. 
For instance, commit e446dd\footnote{Commit id: e446dd6e7f4311f9d85e8e6c4c16b58c193b4edd from app UNCmorfi.} modifies Kotlin code from a file (MenuFragment.kt) that was migrated from Java to Kotlin ten commits before.\footnote{Commit id: 5a2111e9b45552f3aaa7850518734a623eebe6ac from app UNCmorfi.}
\end{comment}
On the contrary, the proportion of commits that migrate files inside the migration interval is lower for other apps.
For instance, the application GPS-Texter has a migration interval of 93 commits and only 15 of them (16\%)  migrate code. 
Those commits are alternated with others that are not related to such type of migration.

\begin{tcolorbox}
We identified two groups of apps, based on their  migration interval lengths:
\begin{inparaenum}[\it 1)]
\item apps which most of the commits from their intervals migrate Files, 
\item apps which migrations of files are \emph{mixed} with  maintenance activities such as refactoring of Java code.
\end{inparaenum}
\end{tcolorbox}

We suspect that file-level migration is done using the auto-converter tool provided by IDEs, which allows developer to migrate a single Java file to Kotlin.

 




\begin{comment}
\begin{figure}[t]
\centering
 \includegraphics[scale=0.45]{scatter_migcommit_vs_miginterval_84.pdf}
  \caption{}
 \label{fig:scatter_migcomit_interval}
\end{figure}
\end{comment}




\paragraph{Fine-grained code migrations}
\label{sec:res:methodlevelmigration}
We found 11 projects (out of 86 fully migrated projects) that contain, at least, one commit that removes one method from a Java file and adds a method in a Kotlin file (Section \ref{sec:method_migration}).
The average and median number of Method-level migration commits on those 11 projects are 2.36 and 2 respectively.
Moreover, we found 13 projects having, at least one commit that removes methods from Java files and, at the same time, adds a new Kotlin file (Section \ref{sec:update_insert_migration}). 
The average and median number of such commits on the 13 projects are 2.3  and  2,  respectively.


We suspect that commits of this type of migration correspond to  migrations written \emph{by hand} because the IDE does only provide (up to now) a tool that converts Java file to Kotlin file.

\begin{tcolorbox}
The migration of Java to Kotlin is mainly done through File-level migrations.
Those convert one Java file to Kotlin and preserve the file names (excepting the file extension).
\end{tcolorbox}

\begin{comment}

\newcommand{\lstbg}[3][0pt]{{\fboxsep#1\colorbox{#2}{\strut #3}}}
\lstdefinelanguage{diff}{

   basicstyle=\ttfamily\tiny,
  morecomment=[f][\lstbg{red!20}]-,
  morecomment=[f][\lstbg{green!20}]+,
  morecomment=[f][\textit]{@@},
}

\begin{figure}[t]
\caption{Commit that migrates one method from Java (left) to Kotlin (right)}
\begin{subfigure}{.20\textwidth}
\begin{lstlisting}[language=diff]
diff --git a/app/.../Preview.java 
b/app/.../Preview.java
index df8bfee..a563fb9 100644
@@ -305,20 +305,6 @@
 .....
-  private int getMaxVideoResolution() {
-      final int maxRes = 
-     mConfig.getMaxVideoResolution();
-      switch (maxRes) {
-          case 0:
-              return 400000;
-          case 1:
-              return 1000000;
-          case 2:
-              return 2100000;
-          default:
-              return 0;
-      }
-  }
...
}
\end{lstlisting}
\end{subfigure}
\begin{subfigure}{.20\textwidth}
\begin{lstlisting}[ language=diff]
diff --git a/app/.../Utils.kt 
b/app/.../Utils.kt
index 436d973..24797c4 100644
@@ -150,5 +150,21 @@
 ...... 
+
+     fun getMaxVideoResolution(config: Config): Int {
+         return 
+  when (config.maxVideoResolution) {
+             0 -> 400000
+             1 -> 1000000
+             2 -> 2100000
+             else -> 0
+         }
+     }
  }
 }
\end{lstlisting}
\end{subfigure}
\label{fig:method_migration}
\end{figure}


Figure \ref{fig:method_migration}  shows as example one of such commits, found in app Simple-Camera.\footnote{Commit: e8cb8d14648a1f8472c266001db0233d69258eeb from app Simple-Camera.}
The commit removes the method named `getMaxVideoResolution'  which contains a Switch-Case statement in its body.
At the same time, the commit adds into an existing Kotlin file (`Utils.kt') a new method also called `getMaxVideoResolution' containing in its body a `When' statement, which is the Kotlin version of the Java Switch-Case instruction.

\end{comment}

\begin{comment}
\begin{tcolorbox}
The file-level  commit migration is much frequent than the method-level commit migration.
However, it still contributes to the migration  from Java to Kotlin of 13 apps.
\end{tcolorbox}
\end{comment}







\subsection{\rqwhymig}


In this section we present the 10 most relevant reason for migrating Java code to Kotlin that we were able to identify from  the 78{} interviews we made with Android developers.


\subsubsection{Reason: To avoid Android platform fragmentation and limitation of Java version for Android development.}

One of the main obstacles that Android developers must face is the fragmentation of the Android platform.
To target all platforms, Android developers which use Java are obliged to use Java 6, which does not include modern features such as \emph{lambdas}.
To use Java 8 and its modern features (incl. collection API, streams and lambdas) their apps must target one of the latest Android OS versions (API level +24).\footnote{Java 8 support \url{https://developer.android.com/studio/write/java8-support}}
This implies that Android devices with older OS versions cannot run those applications written using Java 6. 

Eight developers remarked that programming for Java 6 is ``very stressful".
One of them one told us:
\quotes{In short I was sick of using java. As a professional android developer there is no reason to use java, especially the incredibly limited version of java you get on Android.} 

The majority of the interviewed developers stated that migrating to Kotlin was a way to ``hack'' this problematic: Kotlin provides  moderns features (e.g., lambdas, data class, smart cast, null safe \cite{1907.09003:kotlinfeatures}) 
and its source code is compiled to Java 6 byte-code, thus the apps written in Kotlin can be executed in any Android device.
That simplifies the development task.
For example, one developer wrote: 
\quotes{I forked a library into my project and it was Java 8 only because used streams, but with Kotlin I got that working in Java 6/7 which is how most android works}. 


\subsubsection{Reason: To avoid errors using safer code}

One of the biggest problems in Java is the way it handles \emph{nulls}.
Wrong manipulations of them lead to \emph{java.lang.NulPointerException} (NPE). 
As reported by Coelho et al. \cite{Coelho2015ExceptionsAndroid},  
\emph{java.lang.NulPointerException} was the most reported root cause (27.71\%) found in issues reported from +600 Android projects.
Moreover, they found that 51.96\% of those projects reported at least one exception stack trace on which the NullPoiterException was the root cause.

Kotlin  eliminates the possibility of empty pointers from a compilation perspective: potential NPEs are detected at compile time instead of crashing apps at runtime.

Twenty-four developer states that they decided to migrate to Koltin to obtain a safer code (i.e., \emph{null safety}).
For example, one developer wrote:
\quotes{I researched a bit on the language and the focus on null safety and immutability sold me on trying to avoid some past bugs}.
Another one replied us: \quotes{One of the reasons that motivated me to migrate to Kotlin is Null Safety: reduces errors and I don't have to think if an object may become null}.


\subsubsection{Reason: To follow Google's direction}
Twenty-three developers told us that one of the main reasons of migrating to Kotlin was the fact that Google adopted it as official Android programming language.\footnote{Kotlin official language for Android: \url{https://developer.android.com/kotlin}}
This adoption produced that Google: 
\begin{inparaenum}[\it a)]
\item provides documentations, resources and support for Kotlin development,
\item enriches the IDE Android Studio to support Kotlin,
\item provides \emph{Android KTX}, a set of Kotlin extensions for the Android platform.
\end{inparaenum}
One developer told us:
\quotes{I liked Kotlin but Kotlin was unofficially language at Android development Dec 2016.
But after 1 year, Google announced Kotlin is first-class language for  Android development.
So no more worry about Kotlin being banned and I migrated Java to Kotlin}

The Google's adoption boosted the popularity of Kotlin~\cite{OliveiraSANER20p206}.
For example, one developer told us: 
\quotes{I got interested in Kotlin after I saw some Kotlin snippets in the Android API documentation so I looked into it a bit more and I liked some of the concepts I saw}.

Eight developers also remarked the role of JetBrains, the company that created both the Koltin language and the IDE IntelliJ IDEA. 
One of them told us:
\quotes{Another reason that influenced me into deciding to migrate to Kotlin was the support Kotlin has, being backed up by JetBrains and Google [...]. Since Google is pretty much the Android authority, it's wise to follow the best practices they recommend}.

Also, developers underlined the importance of the IDE Android Studio (which is based on the JetBraind's IDE IntelliJ IDEA).
One told us: \quotes{The IDE support, debug information, and byte code viewer is a killer for senior Android devs to play with}.
There is one prominent functionality that it provides: a tool for automatically converting a Java file to Kotlin \quotes{with the click of a button}. 
One developer told us:
\quotes{Thanks to JetBrains, I migrated it in several hours, and it worked on the first launch, which was very promising}.


\subsubsection{Reason: To use a modern programming language}

Most of developers that answered our questions found that Kotlin is a \emph{modern} programming language that provides several features partially or not available in Java.
Some of them are:
\begin{inparaenum}[\it a)]
\item Coroutines (16 developers highlighted it)
\item Extension Functions (13),
\item Data classes (11), 
\item Lambdas (10), 
\item Collections API (8),
\item among others features (Smart casts, Type inference, Control Flow).
\end{inparaenum}
A developer told us:
\quotes{Kotlin being announced as the primary language by Google, we wanted to keep the product up to date with the latest innovations available in the market}.

We also observed that developers highlighted the ease to adopt Kotlin. For example, one wrote:
\quotes{I believe it provides a great compromise between advanced and modern features (such as functional programming, coroutines, etc) and a very agreeable learning curve. Compared with other advanced JVM languages such as Scala, learning Kotlin is really easy as a Java developer}.



\subsubsection{Reason: For learning purpose}

Fourteen developers mentioned us that they started developing their apps with a learning purpose: 
they used them to try and test new technologies such as Kotlin.
(Note that, beyond that purpose, all those apps were published on apps stores such as Google Play).

Thus, those developers migrated Java code to Kotlin while they were learning to program in Kotlin.
One of them told us:
\quotes{I migrated my mobile application from Java to Kotlin mainly for learning purposes. Even though this project is in production, it is a great playground to stick with the last Android technologies and experiment new tools. Kotlin is really great at reducing the amount of boilerplate code!}.

\subsubsection{Reason: To use a Functional programming language for Android development}

A dozen of developers migrated to Kotlin because it is a \emph{functional-oriented} programming language and it provides several \emph{functional} features not available on Android development using Java 6.
The \emph{Higher-Order functions} feature (i.e. the possibility to pass a function as argument) was highlight by seven developers.
Five developers told us they are mainly Scala developers.
Thus, Kotlin gives those developers the possibility to write Android application using the functional paradigm as they do with Scala.

\subsubsection{Reason: To use features provided by other programming languages
}
Related with the previous point, 
some interviewed developers told us that they are specialized and prefer other no Java Virtual Machine (JVM) programming language such as C, C++, Python or Haskell.
As Android developers were \emph{forced} to program on Java,  the introduction of Kotlin for Android development was an opportunity for those developers to use some features also available in their favorite programming languages.
\emph{Named and default parameters} from Python,  an \emph{Operator overload} from C++ are features present in Koltin that were mentioned by developers in the interviews.

\subsubsection{Reason: Avoid Java language}
Some developers migrated their tools because, as they confessed, they don't like Java language.
Twelve developers mention that, thanks to the possibility to code Android apps with Kotlin, they do not use Java any more.
For example, one wrote: 
\quotes{I don't and haven't ever really liked Java. I only wrote it in Java because that's what Android dictated. When Kotlin came account, it looked like a nicer language, and was fully compatible}.

Since Google official adopted Kotlin, 
developers that  don't like or don't use Java, now have the option of developing Android apps using another programming language.
One of them wrote:
\quotes{I was migrate from Java to Kotlin because I don't really know how to work with Java.  The app was written in java because there was no officially supported alternatives for Android development}.


\subsubsection{Reason: To achieve multi-platform development}
\label{sec:reason:multiplatform}
It's worthy to mention that, even no developer mentioned as the main reason for migrating, 
seven developers pointed that the migration to Kotlin could allow them to achieve multi-(Cross-) platform development.\footnote{Kotlin multiplatform: \url{https://kotlinlang.org/docs/reference/multiplatform.html}}
Currently,  mobile developers have the possibility to write  the business logic of a mobile application using Kotlin and to share it in their Android and iOS projects.
This allow developers to reduce development time and effort by reusing business code.\footnote{Mobile cross-platform: \url{https://www.jetbrains.com/lp/mobilecrossplatform/}}


\subsubsection{Reason: To use a new language 
100\% interoperable with Java
}
Nine developers mentioned the advantage of fully interoperability between Kotlin and Java.
That interoperability allows developers to \emph{mix} Java and Kotlin code, thus the migration can be progressively done.
As said by one developer: \quotes{We could implement new functionality in Kotlin while leaving the existing Java classes intact.
Otherwise, the port to Kotlin would have been infeasible}.
This is aligned with the finding from Oliveira et al. \cite{OliveiraSANER20p206}: their interviews with seven developers presents interoperability as a great benefit of adopting Kotlin.



\subsection{{RQ 4: Are the mobile apps which latest versions have both Java and Kotlin in  process of being migrated?}}
\label{sec:rq:proportion}

\begin{figure}
\captionsetup{justification=centering}
    \centering
 \begin{subfigure}[b]{0.30\textwidth
        \includegraphics[width=\textwidth]{lines_Passandroid.pdf}
        \caption{{\scriptsize PassAndroid}: Amount and proportion of Kotlin code increase.}
        \label{fig:linesPassandroid}
    \end{subfigure}
    \begin{subfigure}[b]{0.30\textwidth}
         \includegraphics[width=\textwidth]{lines_Photolinkviewer.pdf}
           \caption{
          
           {\scriptsize PhotoLinkViewer}:  Amount and proportion  of Kotlin code decrease.
           }
      \label{fig:linesPhotolinkviewer}
    \end{subfigure}
     \begin{subfigure}[b]{0.30\textwidth}
    \includegraphics[width=\textwidth]{lines_Daycounter.pdf}
        \caption{{\scriptsize DayCounter}: Amount of Kotlin code increase, but the proportion decreased.
        }
    \label{fig:linesDaycounter}
    \end{subfigure}

    \caption{Evolution of 3 apps not yet fully migrated. Axis X corresponds to commits, axis Y to sLOC.}
 
    \label{fig:evolutions_trends}
\end{figure}



\begin{table}[t]
\centering
\label{tab:summarybothlang}
 \begin{tabular}{|c |  r r r |r|  } \hline
Latest $c$ & Prop $\uparrow$ & Prop $\downarrow$&  Prop = & Total\\
 \cline{2-5}
 
versus& \multicolumn{4}{c|}{Amount Kotlin  $\uparrow$} \\
\cline{2-5}

\hline
 First  $c$  & 163 (76.17\%) & 35 (16.36\%) & 0 (0.00\%) & 198 (92.52\%)  \\
Recent $c$& 139 (64.95\%) & 13 (6.07\%) & 0 (0.00\%) & 152 (71.03\%)  \\
\hline
\hline
&  \multicolumn{4}{c|}{Amount Kotlin  $\downarrow$}\\
\cline{2-5}
\hline
 First $c$ & 1 (0.47\%) & 4 (1.87\%) & 0 (0.00\%) & 5 (2.34\%)  \\
Recent $c$& 4 (1.87\%) & 22 (10.28\%) & 0 (0.00\%) & 26 (12.15\%)  \\
\hline
\hline
 &  \multicolumn{4}{c|}{Amount Kotlin =}  \\
\cline{2-5}
\hline
 First $c$ & 0 (0.00\%) & 6 (2.80\%) & 5 (2.34\%) & 11 (5.14\%)  \\
Recent $c$& 5 (2.34\%) & 16 (7.48\%) & 15 (7.01\%) & 36 (16.82\%)  \\
 \hline
 \end{tabular}
\caption{The table groups the apps that increase ($\uparrow$), decrease ($\downarrow$) or equality ($=$):
{\it a)} the amount of Kotlin code, 
{\it b)} the proportion of Kotlin code.
For each application, we made two comparisons:
{\it 1)} the latest commit and the first commit that  introduces Kotlin, 
{\it 2)} the latest commit and a \emph{recent} commit with Kotlin. (The letter $c$ means `commit').
}
\label{tab:result}
\end{table}

We now study the evolution of the applications that have not been completely migrated to Kotlin yet (i.e., set  \emph{{Mix-Java-Kotlin Apps}}).
As reported in Section \ref{sec:res:langusedhistory}, the number of such applications is 214 (out of 374). 

We response this research question via two studies.
First, we present a quantitative study based on the evolution of the amount of code computed using {\bf{MigA}}.
Then, we present a qualitative study based on the interviews we made to developers.


\subsubsection{Evolution of Amount of Java and Kotlin Code}
Table \ref{tab:result}  shows the results: each cell corresponds to the number of applications having the amount and proportion of Kotlin code increased~($\uparrow$), decreased~($\downarrow$) and equals~($=$) w.r.t. a previous commit done in the past.
We now discuss three cases of code evolution.



\paragraph{Case 1: Amount of Kotlin Code Increase}
\label{sec:amountincrease}

Let's focus on the first section of the Table \ref{tab:result} (Amount  Kotlin~$\uparrow$).
For the 92.52\% of the applications, the latest commits has more Kotlin code that the first commit that introduced code.
Figure \ref{fig:linesPassandroid}  shows the evolution of the amount of Java and Koltin code from one of those apps.
However, the number of apps that have more Kotlin code in the latest w.r.t a \emph{recent commit} (see definition in \ref{sec:method:amountkotlin}) is lower:  71\%.
Figure \ref{fig:linesPhotolinkviewer} shows the evolution of code from one apps.

Moreover, the 76.17\% of the apps (163 apps) have a larger proportion of code w.r.t the first version.
The percentage is lower when we compare the proportion of the last commit and the \emph{recent} commit: 64.95\% (139 apps).
We believe that those applications are potentially in process of being migrated. 
That situation  could eventually lead into the total migration of the Java code to Kotlin.
On the contrary, for 16.36\% of the apps (35 apps) proportion of Kotlin code has decreased (column Prop $\downarrow$).
This means that those apps have received more Java code than Kotlin.
Figure \ref{fig:linesDaycounter} shows one of those apps: after a total migration to Kotlin, Java code was reintroduced.


\paragraph{Case 2: Amount of Kotlin code decreases}
\label{sec:amountdecreate}
The second section from Table \ref{tab:result} (Amount Kotlin $\downarrow$) shows that few apps (5, i.e. 2.34\%) have less Kotlin code than the initial commit with Kotlin.
However, the 12\% of the apps (26) have less code than their \emph{recent commit}.
We suspect that this reduction is consequence of code refactoring.


\paragraph{Case 3: Amount of Kotlin code remains constant}
\label{sec:amountequals}
Last section from Table \ref{tab:result} (Amount Kotlin~$=$) shows that the 16.82\% of the applications (36) have the same amount of Kotlin code w.r.t the \emph{recent commit} (last row). 
For the 7.48\% (column 3, Prop~$\downarrow$) of them, new Java code is introduced in the latest commits, guiding the evolution of such apps. 


\begin{tcolorbox}
The 64.95\% of the applications having both Kotlin and Java in their latest version evolves increasing both the amount and the proportion of Kotlin code. 
We conjecture that, if those applications continue evolving following that evolution trend, in the near future they could be completely migrated to Kotlin.
\end{tcolorbox}

\subsubsection{Interviews with developers that have not fully migrated their apps}

We asked developers from those not fully migrated apps why they have not finished the migration yet.
We received the responses of 36{} developers (out of 78).
We enumerate the most important reason we identified.


\medskip

{\bf{The ``Boy Scout" rule:}}
Eleven developers migrated Java code to Kotlin by following the \emph{``Boy Scout Rule''}.\footnote{The name `Boy Scout Rule' was given by a developer during the interview. Other developers mentioned the same steps but they did not refer to them like that.}
This rule says that the code is migrated if:
\begin{inparaenum}[\it a) ]
\item it is necessary to make a change to a Java file, and 
\item migrating it to Kotlin is simple (i.e., it takes little time).
\end{inparaenum}
Differently from those developers that completely migrated their code, developers of partially migrated apps only migrated code when there was a particular reason for doing that.
For instance, some of those developers told us that they migrated while doing refactoring.
As one wrote us: \quotes{Occasionally parts of the application that need refactoring are identified. When refactored, they are migrated to Kotlin}.
Another one made refactors while converting: 
\quotes{I converted whenever I had to touch the file for one reason or another anyway, usually combined with a refactoring}.

This way of migrating produces that the amount and proportion of code increase along the evolution of apps (Case 1 from previous section \ref{sec:amountincrease}).

However, some developers remarked us that do not always follow that rule.
For instance, one told us: 
\quotes{Old classes were migrated to Kotlin when they had changes. Some classes are still on java because they implement hard logic}.

\medskip

{\bf{New functionality in Kotlin, old functionality remains in Java:}}
Some developers told us that they decided to only write new functionality in Kotlin without doing any migration of the \emph{old} Java code. 
This means that components written in Java evolve, as difference with the ``Boy Scout'' rule, without doing any migration.
One told us: 
\quotes{I don't think I have yet changed any code just for the sake of rewriting}.
Facing a bug on Java file, those developers continue keeping the Java code.
One mentioned: \quotes{I decided that every new feature would be implemented in Kotlin. I would add java code only to fix legacy code}.

Other developer suggested:
\quotes{not touching the old code unnecessarily. Adhere to the principle of `work - do not touch'. And only when expanding the functionality of the old Java code, translate it into Kotlin}.
Similarly, one replied us: \quotes{If it was working in Java, it'd continue to work}.

This strategy explains why we found in the previous sections applications which proportion and/or the amount of Java code increase along their evolution. 


\medskip

{\bf{Time factor:}} Some developers told us that their applications are still not migrated because:
\begin{inparaenum}[\it a)]
\item they are not in a hurry to complete the migration, or
\item they have not had time for finishing the migration.
\end{inparaenum}
For example, one developer told us: 
\quotes{I am not in a hurry to get to `100\% Kotlin', at least not until the future of `Kotlin Native' (for a possible iOS port) is clear}.
(As we have discussed in Section \ref{sec:reason:multiplatform}, mobile developers can currently reuse their business logic written on Java in the development on iOS and Android apps.)





\subsection{\rqadvise}
\label{sec:advidses}

\subsubsection{Careful Use of Auto-Converter provided by the IDE}
In total, thirty developers told us that they have used the code converter provided by the IDE, which converts a single Java file to Kotlin.
Some of them indicated that they used it while they were learning to code in Kotlin and then, after having more confidence, they continued the migration without using the converter.
In all cases, all developers told us that they  have modified the code after the conversion.
They agreed that the converter helps them to execute the migration and, in general, the changes done into the converted code are simple.
The unanimous  mentioned main reason of doing such changes after the conversion is to turn the converted code more idiomatic.
Three developers mentioned us that they had to modify the converted code to better support nullability e.g. \quotes{It was also marking variables and properties as nullable too often, I was able to make them non-nullable after the conversion}. 
Another developer remarked us some limitations of the auto-converter.
For instance, one told us that the converter does not generate the `lateinit' property.\footnote{lateinit property: \url{https://kotlinlang.org/docs/reference/properties.html#late-initialized-properties-and-variables}}

{\bf Implication:} 
The auto-converted tool provided by the IDE allows Android developer to have an \emph{initial} version of their application in Kotlin.
However, it is necessary to have knowledge on Koltin to modify the generated code with the goal of producing an idiomatic code.
This implies that more research is needed to improve the code conversion from Java to Kotlin.
For example, an initial work by Courtney and Neilsen \cite{CATA2019:Vetting} presents an alternative conversion tool.


\subsubsection{Use of Coroutines to simplify asynchronous tasks}

Asynchronous or non-blocking programming is an important subject on Android because it allows to get better user experiences and to improve the application performance. 
It is used for doing network calls, executing background jobs and task, accessing to local database, and running computational intensive calculations. 
There are several manners of implementing Asynchronous on Android development using Java: AsyncTasks, plain old threads, Android's main looper, Android Loaders, etc.
To simplify the development of Asynchronous task, some Android developers use external libraries (i.e., non-native concurrency API)
such as RxJava (Reactive Extensions for the JVM).\footnote{Concurrency with RxJava: \url{https://github.com/ReactiveX/RxJava}}
Kotlin provides Coroutines: a mechanism, at the language level, for executing Asynchronous task.

Sixteen developers have highlight the Coroutine features.
They agree that it's one of the best features that Kotlin provides.
As one developer told us:
\quotes{In my opinion, coroutines allow developers to write easy to read and concise code, that can be read top-down, like a book. I believe that's a big advantage}.
Another developer remarked: \quotes{coroutines were the cleanest way to implement my complex workflows}.


Seven developers mentioned that they have replaced RxJava by coroutines.
One told us that: 
\quotes{the code with RxJava looks `hacky' and it quickly becomes a mess}, 
and another developer:
\quotes{Coroutines are also absolutely great. They have allowed me to drop RxJava, which although very useful, was annoying to work with in complicated situations. Being able to write asynchronous code in direct style is wonderful}.


Beyond all the positive perceptions we received, 
a single developer told us that, beyond  he uses coroutines, he find them with \quotes{lot of complexity}.

{\bf Implication:} Android developers can simplify the code for their asynchronous tasks using the language-level supported feature `Coroutines'.
Beyond that, further research may be need to compare coroutines with others concurrency mechanisms (e.g. RxJava) in further dimensions such as performance.


\subsubsection{Adoption of Koltin to write less and clearer code than Java}

Twenty developers remarked that Kotlin allowed them to write less code than in Java.
They mentioned that Kotlin has better and clearer syntax than Java, which produces less verbose and  less redundant code.
As one told us: \quotes{Kotlin is a very concise and expressive language} and 
\quotes{Kotlin strikes a good balance between being concise vs cryptic}.
Other eight developers remarked that Kotlin allows to reduce \emph{boilerplate code} i.e., code that have to be included in many places with little or no alteration.
One of the features that allow  to reduce boilerplate code is \emph{Data Classes}: a model class can be declared in one line.
Eleven developers included \emph{Data Classes} between their favorites Kotlin's features.


Furthermore, 
nineteen developers remarked that Kotlin code is easier to read, write and maintain than Java code.
Twelve developer mentioned that Kotlin has a simpler and clear syntax than Java.
(We recall that \emph{all} the interviewed developers have written Java code in their applications before migrating to Koltin).

Nevertheless, between the 78{} developers interviewed, two developers mentioned that, when they started programming on Kotlin,  its compact syntax affected the readability of code.
One told us: \quotes{Initially, it felt awkward, but after a month of practice with the language, it was already obvious that the syntax was much improved over Java}.
This finding is aligned with those from Oliveira et al. \cite{OliveiraSANER20p206}, which found that the overuse of lambdas and closures can decrease code readability.

{\bf Implication:} 
The interviewed developers agreed that
Kotlin allowed them to write conciser, less redundant and more clear code. 
Kotlin helps developer to write and maintain their Android applications.
However, Kotlin's concise syntax could cause difficulties on novice developers.


\subsubsection{Availability of modern features and built-in patterns}

Kotlin languages provides different built-in features that were highlighted by developers. 
One of them is the foremost mentioned Coroutines.
Another one, \emph{Extension function} feature, was mentioned as useful by thirteen developers.
This feature provides the ability to extend a class with new functionality without having to inherit from the class or use design patterns such as Decorator.\footnote{Kotlin Extensions: \url{https://kotlinlang.org/docs/reference/extensions.html}}
One developer wrote us about it: 
\quotes{apart from providing a clean way to refactor the code, extensions allow an alternative to Abstraction/Inheritance in order to achieve the Open/Closed Principle, which is invaluable}.


Five developers remarked the \emph{built-in design patterns} provided by Kotlin, which enforces some of the best practices of Java by design.
For example, \emph{Singleton} pattern using the keyword `Object' and \emph{Decorator} pattern using keyword `By'.

Also, most of interviewed  developers remarked the importance of Kotlin standard libraries, which provide support in, for instance, Collections.
Fourteen developers remarked the importance of having lambdas and streams. 
As one developer said: 
\quotes{Android development stuck on old Java version without e.g. streams (supported only on API 23+). Kotlin standard lib fills these shortcomings}.  

{\bf Implication:} Using Kotlin, Android developers have the possibility to use a modern programming language, with features not always available on Java, and, at the same time, to reach all Android platforms. 








\section{Threats of Validity}
\label{sec:tov}

{\hspace{0.5cm} \bf{Studied Applications.}}
In this paper we study open-source Android applications coming from {FAMAZOA}{} \cite{GoisMateus2019}.
There is a risk that the applications studied in this paper  could be not representative of open-source Android applications written in Kotlin.
However, to our knowledge, {FAMAZOA}{}  is the largest dataset of open-source code Android application totally or partially written  in Kotlin.

{\bf{Open-source Apps not representative of Android Apps.}}
Most of the apps available in the apps store such as Play Store are not open-source, which means that only the APKs (byte-code) of apps are available.
Our framework {\bf{MigA}}{} studies the migration of applications at the source code level, thus to study the migration is necessary both the source code and a code repository such as GIT.


{\bf{Representativeness of interviewed developers.}}
It could be the case that the interviewed developers do not represent the Android community because our study analyzed their open-source applications. 
However, from our interviews we got that the majority of the interviewed Android developers work on the industry.

{\bf{Survey sample.}}
Surveys are done though taking a sample which is representative to the population under study \cite{experimentationSE2012}.
In our survey, we did not take a sample: we sent emails with questions to \emph{all} developers that migrated Java code to Kotlin from \emph{all} applications available on F-Droid, the largest Android open-source app store, and on AndroidTimeMachine \cite{Geiger2018:data},  from which we created our dataset of Kotlin applications named FAMAZOA \cite{GoisMateus2019}. 


{\bf{Faithfulness of Answers.}}
It could be the case that some answers do not faithfully reflect the experiences of the developers that answered them.
As we have a considerable number of replies (78) potential imprecise or incorrect answers do not invalidate the overall results presented by this paper. 


{\bf{Accuracy of {\bf{MigA}}{}.}}
There could be a risk that a bug in our tool affects the results we present in this paper.
To mitigate the risk, we manually inspected the results.
The inspection consisted on:
\begin{inparaenum}[\it a)]
\item randomly selecting 20 applications with migrations (out of 269 apps with 1+ migrations),
\item for each selected app, to randomly select 5 commits that migrate Java code,
\item for each selected commit, we used a GIT client to retrieve the commit information (files affected, diffs),
\item we crossed that information with that one retrieved by {\bf{MigA}}: for example, if {\bf{MigA}}{}  reported that a file F was migrated from Java to Kotlin by commit C, we checked that commit C removes a file F.java and adds a file F.kt.
\end{inparaenum}
We did not find any anomaly.


\section{Discussion and Future work}
\label{sec:discussion}

\subsection{Future Uses of {\bf{MigA}}{}}

{\bf{MigA}}{} can be used by other researchers to study the evolution of the migration activity of applications written in other program languages.
{\bf{MigA}}{} can be extended using the extension mechanism provided by the underlying platform (Coming \cite{coming2019}).
A researcher can add: 
\begin{inparaenum}[\it a)]
\item new programming language parsers (currently {\bf{MigA}}{} provides parsers for Java and Kotlin, and
\item new analyzers (in addition to those presented in Section \ref{sec:architecture}).
\end{inparaenum}

One of the future direction we plan to study is the detection of migration change patterns.
This will allow us to detect commits that migrates code which do not fall into the three types of migration commits we defined in Section \ref{sec:commit_migration}.
For that, we define \emph{inter-languages change pattern} as a pattern which captures frequent changes involving two or more languages.
We aim at detecting
\emph{Inter-language change patterns} that occur on commits that affect both Kotlin and Java files.
We now present an initial experiment in that direction.

\subsubsection{Discovering Inter-language change patterns}
\label{sec:inter-patterns}
We carried out a first experiment for discovering Inter-language change patterns.
We applied frequent itemset (FIS) algorithm \cite{Agrawal:1993:MAR}, in particular Apriori algorithm \cite{Agrawal:1996:FDA},
on commits that update one or more Kotlin files \emph{and} one or mode Java files.
A \emph{frequent itemset} is, given examples that are sets of items and a minimum frequency,  any set of items that occur at least in the minimum number of examples \cite{Toivonen2010}. 
We created an itemset per each commit, where each item is a single AST change.
Each itemset has 1 or more changes on the Java AST \emph{and} 1 or more changes on the Kotlin AST.
As mentioned in Section \ref{sec:architecture} {\bf{MigA}}{} outputs this information per each commit.
We applied FIS over the changes extracted from 422 commits that update both Java and Kotlin, those commits come from 33 migrated apps (note that the remaining 53 out of 86 apps from set \emph{{Migrated-Apps-j2k}{}} do not have any commits that updates both Java and Kotlin).

Table \ref{tab:apriori} shows a sample of the most frequent \emph{inter-language change patterns} we found using FIS. 
The first row shows that the 1.6\% of the commits analyzed update a Method Invocation located inside a Java method  \emph{and also} it updates method Invocation located inside in a Kotlin Function.
One frequent item (row 7) corresponds to the method-level migration discussed in Section \ref{sec:res:methodlevelmigration}.
However, beyond that pattern,  most of frequent itemsets do not  remove code.
This can be explained by the fact that, when migrating, developers also need to update the remaining Java code (e.g., to update the references to the migrated code).
We leave for future work the research on other pattern detection algorithms.


\subsection{Further characterization of migrations}

One of our goals was to understand which functionality was migrated to Kotlin.
We aimed to respond the question: \quotes{Which functionality was migrated to Kotlin?}.
Most of developers confirmed us that they have started the migration by migrating POJO (Plain Old Java Object) to Kotlin's \emph{Data Classes}.
They all agreed that is a straightforward and simple migration.
However, beyond that finding, due to the diversity and complexity of the answers, we could not develop generalized conclusions about which functionalities.
We let this question open for future work.


\subsection{Ethics in Experimentation}

As our experiment involved human subjects, as recommended by \cite{experimentationSE2012},  we took ethical aspects into consideration when we designed the survey:
\begin{inparaenum}[\it 1)]
\item We informed the research project's  title and goals,
\item We mentioned our affiliations and we provided  links to our professional web sites,
\item we explained that their participation will help us to create a research paper,
\item We guarantee the confidentiality of the information obtained i.e., we do not share the interviews,
\item  every quote included in this research was anonymized.
\end{inparaenum}


\begin{table}[t]
\tiny
\centering
 \begin{tabular}{|l |l|l|} 
\hline
{\tiny Size}&{\tiny Support}&Frequent Item sets\\
\hline
\hline
2 &1.60 \%&  UPD-Invocation in Method (J), UPD-Method Invocation in Method (K)\\
\hline
2 &0.94 \%&  UPD-Local Variable in If (J),UPD-Method Invocation in Method (K)\\
\hline
2 &0.94 \%&  UPD-Invocation in Method  (J), UPD-Property Declaration (K)\\
\hline
2 &0.75 \%& UPD-Local Variable  in Method (J),  UPD-Method Invocation inside If (K)\\
\hline
2 &0.72 \%&  UPD-Invocation in Method (J), INS-Method in Class (K)\\
\hline
\multicolumn{3}{|c|}{...}\\
\hline
2 &0.42 \%&  DEL-Method in Class (J), INS-Method in Class (K)\\
\hline
\multicolumn{3}{|c|}{...}\\
\hline
4 &0.40 \%& DEL-If in Method (J), DEL-Assignment in If (J),\\
 &&  UPD-Local Variable Method (K), UPD-Method Invocation in If (K)\\
\hline

\multicolumn{3}{|c|}{...}\\

\hline

 \end{tabular}
\caption{Sample of most frequent item sets. Each item is composed by
a) action (Insert, Delete, Update),
b) entity type (e.g., Invocation),
c) language (`J' for Java, `K' for Kotlin).
}
\label{tab:apriori}
\end{table}




\begin{comment}
\begin{table}[t]
\scriptsize
\centering
 \begin{tabular}{|r |r|l|} 
\hline
Keyword&\#Projects&Example Message from a Migration Commit \\
\hline
conver*& 46&``Convert to kotlin"\footnote{KonashiInspectorForAndroid de2ef34a6f5fff43dc8859486247bf94edb89a34} \\
migrat*& 15&``Start Kotlin migration - Api service/ Programs repository"\footnote{Podcasts-RAC1-Android 7bd1f135a336709cffa8a94644b64f9831e9f32f}\\
rewrit*& 11&``Initial implementation of rewriting the app in kotlin"\footnote{Simple-Flashlight 18b5c9de46da44821cd2147b34be92110dfd72a9}\\
updat*& 8&``Updated to Kotlin and targeting newer Android api"\footnote{SimpleHTMLTesterAndroid 82d3acdccf6d852d72f44bb7e1a78153d50f2aef}\\
port*& 7&``Start port to Kotlin"\footnote{whitakers-words-android a83ad0796a36269a8606e8befb1e964af38015f9}\\
switch*& 4&``Switching to kotlin"\footnote{hand-and-foot-scores49463cf5b272d49c2ba5f39dd5229f7012ea1301}\\
transf*& 2&``Transformed everything to Kotlin"\footnote{Status-Bar-Tachometer- d32f2eab56675d3870653feecaf232f7a460c466}\\
mov*& 1&``Moving to MVP, RxNetty, RxJava, Kotlin"\footnote{ScreenStream c2c4f667e7a25c8dc4f8f7b02e85d0c626eee183}\\
shift*& 1&``Shifting code to Kotlin"\footnote{NCBSinfo-0eacb144f26b4b6af607d77f4ae0ae52bed262f1}\\
...&...&...\\
Others&15&``Kotlin initial", ``MatchMV $->$ Kotlin"\\
\hline
 \end{tabular}
\caption{Keywords found in the messages written in migration commits. `*' means a sequence of any character. A project can have more than one keywords in their  commit messages.}
\label{tab:messages}
\end{table}

\subsubsection{Message of Migration Commit}
\label{sec:commit:messages}

Table \ref{tab:messages} shows, for each keyword that may suggest migration, the number of migrated apps having at least one of those keywords in their commit messages.
The most used work is `Conver*' which encompasses `Convert' and `Converted'.
This may suggest that developers could use some conversion tool, such as those included in the Android Studio IDE for passing from Java to Kotlin. 
On the contrary, the prefix `rewrit' is the third most used word,  and may suggest that those migrations could be done ``by hand" by developers, i.e., without the assistance of any code conversion tool.
We will investigate more about the use of such tools in future work.
\end{comment}



\section{Related Work}
\label{sec:rw}

The two most related work are from Coppola et al. \cite{Coppola:2019:CTK} and Oliveira et al. \cite{OliveiraSANER20p206}.

Coppola et al.  \cite{Coppola:2019:CTK}
have analyzed a set of open-source Android apps, to evaluate their transition to the Kotlin programming language throughout their lifespan and understand whether the adoption of Kotlin has impacts on the success of Android apps.
Our work complements that work and goes one step further in the characterization of Android app migrated to Kotlin.
First, as difference with that study, which is based on metrics that measure the amount of code, our study goes deeper: we aim at detecting and characterizing the commits that migrate code.
Secondly, we aim at knowing the reasons of the migrations. For that, we interviewed developers that have already done migrations from Java to Kotlin. That is not covered in \cite{Coppola:2019:CTK}.
As mentioned, both works are complementary: Coppola et al. \cite{Coppola:2019:CTK} studied the quality of the migrated apps by inspecting the popularity of those apps in the App Store. 
The goal of our paper is not to study the reputation, popularity or quality of the migrated apps, but the reasons of the migrations, not only limited to Java and Kotlin.
Finally, our work contributes with a framework, {\bf{MigA}}, which allows researchers to do more research on applications migrations.

The second most related work is from Oliveira et al. \cite{OliveiraSANER20p206}, which 
conducted a study to understand how developers are dealing with the recent adoption of Kotlin as an official language for Android development, their perception about the advantages and disadvantages related to its usage, and the most common
problems faced by them.
Their study is based on the analysis of questions and answers mined from StackOverflow and on interviewers with seven developers. 
Our work, as difference with them, has a narrower goal: to study the \emph{migration} of Android applications from Java to Kotlin.
In particular, we aim to analyze the history of migrated applications (in particular, we analyze commits), while they analyzed questions and answers.
Even, their work  and our work have done interviews, there are three main differences between both surveys:
\begin{inparaenum}[\it 1)]
\item goal: the interviews' goals: experience of adoption \cite{OliveiraSANER20p206} vs experience of migration (us),
\item modality: recorder \cite{OliveiraSANER20p206} vs email (us)),
\item size: 7  interviewees \cite{OliveiraSANER20p206} vs 78{} (us) interviewees.
\end{inparaenum}


{\bf {Studies on Kotlin:}}
As Kotlin becomes to be used more and more used,   researchers have conducted different studies about this language.
Gois Mateus and Martinez \cite{GoisMateus2019} have found that the 11\% of the studied open-source applications from Android have Kotlin code.
Moreover, they studied the quality of such apps in terms of presence of code smells.
They found that the adoption of Kotlin increase the quality of applications.
Flauzino et al. \cite{Flauzino:2018:YSS} have studied 100 repositories of programs (not only Android apps) containing Java or Kotlin code (but not both) and they found that on average Kotlin programs have less code smells than Java programs.
In this paper, as done by those papers, we don't study the quality of the migrated apps. 
An initial work on that directions were done by \cite{Coppola:2019:CTK}.
Gois and Martinez \cite{1907.09003:kotlinfeatures} have studied the adoption of the features introduced by Kotlin, finding that some Kotlin features are more used than others. In this paper, we don't study the adoption of such features during the migration.

\begin{comment}
Coppola et al.  \cite{Coppola:2019:CTK}
have analyzed a set of open-source Android apps, to evaluate their transition to the Kotlin programming language throughout their lifespan and understand whether the adoption of Kotlin has impacts on the success of Android apps. Our work, as difference of them, study migration at the level of commits with the goal of detecting and characterizing the commits that produce the transition to Java to Kotlin.
\end{comment}

Other works have focused on helping developers to develop Kotlin apps.
For example, Courtney and Neilsen present a tool, named  j2kCLI \cite{CATA2019:Vetting}, that allows users to  translate Java code to Kotlin,  faster than the same functionality provided by Android Studio, the IDE from JetBrains to create Android apps. (We recall that the JetBrais company drives the development of Kotlin language.)

From the JetBrains research group, Bryksin et al.  \cite{Bryksin:2018:DAK}  studied anomalies, in particular, code fragments that are written in some  way that is not typical for the programming language community, from in a large corpus of Kotlin code using different machine learning techniques. Those anomalies are of great interest to language developers.











{\bf Code Migration:}
Other works have focused on the code migration of other program languages. 
For example, Malloy and Powell \cite{Malloy2017Python, Malloy2019} focus on the migration of Python 2 to Python 3.
They measured and quantified the degree to which Python 3 features are being used, as well as the rate and context of their adoption. They found that Python software developers are not exploiting the new features and advantages of Python 3.
To our knowledge no work has studied the migration of Java or Kotlin code.


Other works focus on empirical studies of migration of libraries  \cite{Teyton:2014:SLM, Kula:2018:DUL, hora2018sqj} and recommendation of library migrations \cite{Alrubaye:2019:UIR}.
Salza et al. \cite{Salza:2018:DUT} focus on studying the update migration of  third-party libraries in mobile Apps.  They found that mobile developers rarely update their apps with respect to the used libraries.
Our study does not cover on the migration of libraries but on the migration of the source code that forms a mobile application.



{\bf Mining changes using data mining techniques:}
We showed in Section \ref{sec:inter-patterns} that the output of {\bf{MigA}}, in particular, the AST changes from migration commits, can be further analyzed to extract knowledge such as migration patterns from migration commits. 
Previous work has applied similar technique on code changes. For example, 
Negara et al. \cite{Negara:2014:MFC} applied frequent item set to detect change patterns from changes done by developers when they write code using IDEs.
Zimmermann et al. \cite{Zimmermann:2004:MVH} data mining techniques  to obtain association rules from version histories for suggesting and predicting likely further changes.
Similarly, Ying et al. \cite{Ying:2004} also used association rule mining to determine the change patterns.
Viggiato et al. \cite{VOFJK:ICSME19}  also used Apriori algorithm to find types of changes that frequently co-occur  in mobile and non-mobile
platforms. 
Our experiment, as novelty, focuses on mining patterns composed by changes done in different languages.






\section{Conclusion}
\label{sec:conclusion}

In this work we have presented an empirical study that focuses on characterizing the Android applications that have been migrated from Java to Kotlin.
We interviewed 78{} developed that have migrated code from Java to Kotlin to ask them \emph{Why} they migrated code.

To understand \emph{How} developers migrated, we develop a tool named {\bf{MigA}}{} that analyzes the history of one application (e.g., the GIT repository). The tool is able to retrieve the commits that migrate code. 
Our results show that developers migrates Android apps by mostly:
\begin{inparaenum}[\it a)]
\item converting Java files to Kotlin files, and
\item doing consecutive few commits.
\end{inparaenum}

In future work we plan to study the use of tools for automatically converting code from Java to Kotlin such as those included on the IDEs such as Android Studio: most of the interviewed developers remarked us that the output of current auto converters needs to be modified.
Moreover, we aim at proposing approaches that help developer to carry out the migration of application initially written in Java to Kotlin.


\section*{Acknowledgements}

We would like to acknowledge to the 78{} developers that had the courtesy to accept our interviews and to respond our questions done by email.

\bibliographystyle{plain}
