MigrationMiner: An Automated Detection Tool of Third-Party Java Library Migration at the Method Level

Abstract

In this paper we introduce, MigrationMiner, an automated tool that detects code migrations performed between Java third-party library. Given a list of open source projects, the tool detects potential library migration code changes and collects the specific code fragments in which the developer replaces methods from the retired library with methods from the new library. To support the migration process, MigrationMiner collects the library documentation that is associated with every method involved in the migration. We evaluate our tool on a benchmark of manually validated library migrations. Results show that MigrationMiner achieves an accuracy of 100%. A demo video of Migration-Miner is available at https://youtu.be/sAlR1HNetXc.

Learning to recommend third-party library migration opportunities at the API level

“…The migration process between libraries is widely acknowledged to be a hard, error-prone, and timeconsuming process [6], [2], [3], [1]. Hence, developers have to explore the new library's API and its associated documentation in order to locate the right API method(s) to replace in the current implementation that belongs to the retired library's API.…”

“…For instance, Figure 1 shows that developers who have more than ten years of experience are expected to perform migration more often than a new developer with less than five years of experience. The figure is based on a previous migration benchmark by Alrubaye et al [6] which contains information about the developers who have performed migration tasks previously, such as, developer names, emails, years of experience, and migration dates. Furthermore, we find that 95.3% of 57,447 Java projects use at least one third party library (APIs).…”

“…in such a way that each source method m (i) s ∈ L s is mapped to an equivalent target method m (i) t ∈ L t , this process is called Method Mapping. Figure 2 provides an overview of RAPIM approach which consists of two main phases: the first phase, called (1) Collection Phase, collects the necessary information, e.g., library documentation, for all the mappings contained in the data set [6], to generate the features. This phase starts with (A) the collection of APIs and their corresponding documentation; (B) text preprocessing, and (C) the feature engineering that used to extract the feature from method signature and API documentation.…”

On the Use of Information Retrieval to Automate the Detection of Third-Party Java Library Migration at the Method Level

“…The migration process between two different libraries is a hard, error-prone and time-consuming process [1], [2], [17], [18]. To showcase the complexity of the process, we measure, based on the data we collected in our experiments, the average time spent to perform migration between different libraries as shown in Figure 1.…”

“…In the following, we explain each of these phases. For the fragments collection and detection, we reuse dataset of our previous study [17].…”