dataesr/scientific-paragraphs-categorization huggingface dataset:
Memory task in virtual reality The memory task was carried out in a virtual urban environment representing a city inspired by Paris with buildings, passers, signs and background sounds evoking an urban environment. It was constructed with Virtools and in-house software for creation and visualization of virtual environments (EditoMem and SimulaMem). The same task has been already employed by Abram, Cuny, Picard, and Piolino (2014) and  Debarnot et al. (2015). The participant moved with a joystick and followed street signs indicating the route leading to the train station. This was done to be sure that all participants followed the same itinerary and, thus, met the same events in the same order.
As the Android API evolves, some API methods may be deprecated, to be eventually removed. App developers face the challenge of keeping their apps up-to-date, to ensure that the apps work in both older and newer Android versions. Currently, AppEvolve is the state-of-the-art approach to automate such updates, and it has been shown to be quite effective. Still, the number of experiments reported is moderate, involving only API usage updates in 41 usage locations. In this work, we replicate the evaluation of AppEvolve and assess whether its effectiveness is generalizable. Given the set of APIs on which AppEvolve has been evaluated, we test AppEvolve on other mobile apps that use the same APIs. Our experiments show that AppEvolve fails to generate applicable updates for 81% of our dataset, even though the relevant knowledge for correct API updates is available in the examples.
We first categorize the limitations of AppEvolve that lead to these failures. We then propose a mitigation strategy that solves 86% of these failures by a simple refactoring of the app code to better resemble the code in the examples. The refactoring usually involves assigning the target API method invocation and the arguments of the target API method into variables. Indeed, we have also seen such transformations in the dataset distributed with the AppEvolve replication package, as compared to the original source code from which this dataset is derived. Based on these findings, we propose some promising future directions.
I. INTRODUCTION In recent years, each release of Android has seen the deprecation of some APIs and the introduction of new ones. Due to the fragmentation of the Android market  [12] ,  [16] , app developers must update their apps to use the new APIs, while maintaining backward compatibility. Unfortunately, updating API uses is not always trivial. While API changes are described in the documentation, these descriptions are not always accompanied by concrete examples. When an API is used at many places in the app source code, updating its uses is tedious and error prone. AppEvolve was recently proposed by Fazzini et al. [10]  to automate the updating of Android apps in response to deprecations of Android APIs. The main idea of AppEvolve is that many software projects may use the APIs in similar ways, and thus existing codebases may already contain examples of how to update uses of deprecated APIs.
Given a target app that uses a deprecated API and information about the new API method(s) that should replace it, AppEvolve collects update examples from existing codebases, abstracts their variable references, ranks them according to their expected applicability, and then tries to apply the abstracted examples one by one to the target app. If an abstracted example matches the code, the update is said to be applicable. Applicable updates are furthermore validated by testing. A key feature of AppEvolve is that it does not merge the abstracted examples into a single generic pattern, to avoid losing information that may be specific to particular usage contexts. AppEvolve has been evaluated on a dataset involving 15 real-world apps and 20 real API changes. The dataset contains 41 usage locations of these real API changes.
AppEvolve successfully produced validated applicable updates for 85% of these API changes and 90% of their usage locations. The paper on AppEvolve is accompanied by a replication package, containing the tool and the dataset. 1  We have reproduced the results of AppEvolve on this dataset. In this work, our goal is to understand the generalizability of the results reported for AppEvolve, and to analyze the characteristics of the apps for which AppEvolve cannot generate applicable updates. To this end, we consider the same APIs and change examples as used in the AppEvolve evaluation, but create a new dataset of target apps. In selecting the new target apps, we make no effort to take the expected strengths or weaknesses of AppEvolve into account, and only check that the apps use one of the deprecated APIs considered in the AppEvolve dataset and do not use the corresponding replacement API.
Of the apps we found at GitHub that satisfy these properties, we randomly selected 54 mobile apps that are entirely distinct from the original data set, and that involve 14 of the 20 real API changes and 54 usage locations. We applied AppEvolve to update the deprecated-API usages in these mobile apps and analyzed the cases where it fails to update the apps. Indeed, running AppEvolve on our dataset generates applicable updates for only 10 out of 54 usage locations. It generates only failed updates, i. e. , updates that do not match the deprecated-API invocation, for the remaining 44 usage locations. Our analysis shows that AppEvolve produces applicable updates for a mobile app in cases where the API usage closely matches an API change example. On the other hand, AppEvolve often fails to update a mobile app when there are minor syntactical differences between the invocations of the deprecated API in the target app and the change example.
It also fails when there are semantic differences, such as the use of inheritance or the use of static or final modifiers, when encountering edits that require modifications beyond method boundaries, and when finding no relevant change examples in GitHub. Of these limitations, only the latter two were mentioned in the AppEvolve paper. To try to understand the issues leading to the drastic performance difference as compared to the results of the original AppEvolve evaluation, we refactor the use of the deprecated in the target app code so that it more closely resembles the uses found in the change examples from which AppEvolve learns the edits. After refactoring, we found that AppEvolve can generate applicable updates for 86% of the cases where it previously failed to do so. Based on these results, we propose to mitigate the dependence of AppEvolve on the code structure of the examples and the deprecated API usage by normalizing the code to a standard form coupled with the use of identifiername recommendation, to improve existing work on automated deprecated-API usage updates for Android apps.
The main contributions of this paper are as follows: • We evaluate AppEvolve with additional Android apps to investigate if it can effectively perform API-usage updates in different situations. The dataset that we created contains three times more real-world apps than those used to evaluate AppEvolve in the original paper (54 vs 15). • We categorize the limitations of AppEvolve and show API usage instances that are affected by these limitations. • We discuss how the limitations may be overcome to improve the automatic API-usage updates for Android apps. • We release a replication package to allow easy replication and evaluation of our experiments and results. 2  The remainder of this paper is structured as follows. Section II describes AppEvolve, the state-of-the-art work on automated updates of deprecated API usages in Android apps.
Given this example and the mapping getCurrentHour → getHour, AppEvolve learns a generic patch for getCurrentHour() as shown in Figure  2. The generic patch updates a deprecated method getCurrentHour usage to a replacement method getHour usage. I and M mean that the corresponding piece of code are inserted and modified, respectively. Backward compatibility is achieved by checking the version number of the mobile OS running the app. If the version is greater than or equal to a certain version number, the replacement method is used. Otherwise, the deprecated method is used. Note that AppEvolve can only perform API usage learning and update one mapping at a time. Thus, even though getCurrentMinute is also a deprecated method, App-Evolve does not learn how to update it since this case is the mapping getCurrentHour → getHour.
Consider the deprecated API method getCurrentHour() mentioned in Section II-A. In this case, the API Usage Change is the replacement of getCurrentHour() with getHour(). Given this information, AppEvolve finds the location in the Target App that invokes getCurrentHour(). 2) Update Example Search: AppEvolve searches for apps in GitHub that use both the deprecated and the replacement API methods in their latest versions. For each such app, AppEvolve looks through the app history to find the commit where the uses of the replacement API methods are added. This is intended to find examples that produce a backward compatible Android app. For each of these apps, AppEvolve finds the changes that add the replacement API method to the app code that already contains the deprecated API method. These changes are the examples that can be used to update deprecated API method usages in other apps.
A. Dataset Our replication study focuses on the same set of deprecated API methods as the original evaluation of AppEvolve and relies on the same set of change examples, but considers a different and larger set of mobile apps that use these deprecated methods. We find the mobile apps for our dataset by querying GitHub Code Search 4  using the names of the APIs. GitHub Code Search returns a list of ranked files matching the query. Since Github Code Search only supports textual queries, it returns many false positives, i. e. , files that do not actually use the API methods that were queried for. Thus, we manually check that the considered files contain usages of the desired deprecated APIs. We additionally check that the considered files do not use the replacement APIs. From the files that pass these checks, we randomly select 54 API usages, each from a different app, as our dataset.
B. Procedure For each app in our dataset, we must create an AppEvolve configuration. To do so, we first carefully studied the configurations that were used in the original AppEvolve experiments. We also asked the first author of AppEvolve to confirm how to configure AppEvolve correctly. Finally, we ran our  experiments in the virtual machine environment provided by the AppEvolve authors. 5 fter configuring AppEvolve for the apps, we ran App-Evolve on them. We recorded the number of applicable and failed updates. We then categorized the failed updates using card sorting  [30]. For this, the first two authors performed multiple passes on the failed updates. In the first pass, they put each of the failed updates into a category created based on our understanding of the reason for the failure.
IV. FINDINGS On our dataset, AppEvolve produces 10 applicable updates and 44 failed updates (19% success rate). The original AppEvolve evaluation also showed 4 failed updates. After investigating the 48 failed updates, we found some common reasons for the failures, as described below. Table  I  shows the number of occurrences of each of these issues. 1) The statements in the examples and at the target location are structurally different. AppEvolve infers edit operations at the statement level (insert a statement, move a statement, etc). Accordingly, AppEvolve is not able to apply changes inferred about method uses found in one kind of statement to a method use found in another kind of statement. We have observed that in the examples used in the evaluation of AppEvolve, it often occurs that the invocation of the deprecated API method is used as the right hand side of an assignment, while in our dataset the API method invocations occur in a variety of expression contexts.
We now present some examples: 2) Object and arguments of the deprecated API method are complex expressions. In creating edits, AppEvolve only abstracts over variables. Accordingly, when examples always contain variables for the object or the arguments, the generated edits are not sufficient to update code in which these subterms are expressed as more complex expressions. In the code shown on the left side of Listing 6 in Table  II , an invocation of the deprecated method setTextAppearance involves expressions that do not have the form of a simple variable for both the object and arguments. 3) Edits beyond method boundaries. AppEvolve cannot learn edits that modify program elements that reside outside of the method containing the API usage to be updated. These edits include operations such as adding imports and adding fields to a class.
Below is a snippet of an update example that involves edits beyond method boundaries. The above example involves a use of the deprecated API addGpsStatusListener. Updating a use of this API requires adding a private field callback of type GnssStatus. Callback. Since AppEvolve only learns edits inside a method containing the deprecated API usage, it misses this necessary addition. In the AppEvolve paper, this category is described as missing context information. 4) Specific programming language features. AppEvolve fails to update cases in which the update involves programming language features such as: • Static modifier: The code on the left hand side of Listing 7 in Table  III  shows an example of this case. The deprecated API method requestAudioFocus is invoked by mAudioManager, which is a static field.
V. MITIGATIONS To mitigate the observed failures, we tried to modify the deprecated API usages in the target app's source code so that AppEvolve could produce an applicable update. Looking at the 10 apps that were updated successfully, we observe that in each case the invocation of the deprecated method appears as the right-hand side of an assignment statement, or any arguments of the deprecated method are simple variables. We transform the remaining apps where possible accordingly, converting the invocations of the deprecated APIs to a form reminiscent of the three address code used in compiler intermediate representations  [1]. In essence, our mitigations refactor the deprecated method invocation in the target app to resemble the examples from which AppEvolve learns edits. The right side of Table  II  shows a diff that applies these mitigations on the cases presented in Section IV where the mitigation allows AppEvolve to produce applicable updates.
A. Result Assessment We were initially surprised by the large difference between the results on our data set, where we obtained a success rate of 19%, and the results reported by the authors of AppEvolve, who obtained a success rate of 85%, even though our dataset was constructed randomly, without taking into account the strengths or weaknesses of AppEvolve. Indeed, given that AppEvolve relies on matching statements, abstracting only over variables, it is surprising that AppEvolve could achieve such high accuracy on e. g. simple getter methods such as getCurrentHour() (e. g. , Listing 3). In our dataset, such methods are often used as subexpressions of arbitrarily complex statements, which may contain project-specific code. Likewise, as illustrated by Listing 2, invocations of method calls may have arbitrarily complex, possibly project-specific, arguments that are not likely to be found in other codebases.
To understand better how AppEvolve is able to achieve a high rate of success in the previously reported evaluation, we investigate the examples and target apps used. Given the difficulty of finding the original files for the examples, for which no origin information is provided, we focus on a single example, the call to getCurrentHour() in the app CONVERSATIONS version 1. 8. 0 in F-Droid (A02-U03 in the AppEvolve paper). In F-Droid, we find that the only invocation of getCurrentHour() occurs in the argument list of a call to the set method of the Calendar class, a code structure similar to the code shown on the left side of Listing 3. In the AppEvolve dataset, this call is extracted into a separate statement, analogous to our mitigation shown on the right side of Listing 3. We have furthermore looked at one of the examples provided for this API, and have found the original code on GitHub in the file RepeaterDialogFragment.
B. Future Directions Code Normalization. Our above analysis suggests that our mitigation succeeds because the AppEvolve authors have already performed such a mitigation in the change examples included in the AppEvolve replication package. To improve the results of AppEvolve in the more general case, a solution could be to systematically first normalize the change examples to a standard form. Edits can then be learned from this standard form. When the edit is applied to a new piece of code, that target code should also be normalized, to minimize the code variations. If the edits are successfully applied, the resulting code can then be refactored again to restore the coding style of the developers. Our mitigations represent a subset of the normalizations that may be possible. Coding Style and Readability.
Any tool that automatically transforms code runs the risk of converting the code to a style that is incompatible with the preferences of the given app's developers. In the case of AppEvolve, there is already the risk of changing the existing coding style to the coding style found in the app providing the change example, and any normalization performed to the target code further increases this risk. To assess the impact of AppEvolve on coding style, we perform a simple experiment to compare the output of AppEvolve after applying our mitigation with code that is manually updated to deal with a set of deprecated APIs. We asked a software engineer who is not an author of this paper to update the code shown on the left hand side of Listing 4 in Table  II  Semantic Preservation. The code made manually by the engineer is substantially different from the code produced by AppEvolve, and developers may indeed prefer the code made by the engineer.
C. Threats to Validity One threat is related to whether we have configured App-Evolve correctly. To mitigate this threat, we have tried our best to run AppEvolve following the instructions given by the authors in the AppEvolve documentation. We have also asked AppEvolve's first author how to configure AppEvolve correctly for new mobile apps. Based on the information obtained, we independently reconstructed the configurations for the target apps in the original dataset, and using these configurations were able to reproduce the results reported for that dataset. We have also rechecked our configurations for the new dataset several times. We have released a replication package for others to check and validate. 6 nother threat is related to the generalizability of the findings. We have added 54 new applications to evaluate the effectiveness of AppEvolve in generating applicable updates.
This translates to 54 API usage locations on top of the 41 API usage locations in AppEvolve dataset, thus more than doubling the number of API usage locations and more than tripling the number of apps as compared to the dataset used in the original work. We believe this is sufficient to understand the capabilities of AppEvolve, as 44 of the 54 API usages that we have added uncover limitations of AppEvolve. There might be other cases that AppEvolve cannot handle, but we believe that we have found many of them.
C. Program Transformation Normalization of code to improve the results of program transformations has a long history. It was extensively used in the early 1990s in the context of partial evaluation (specialization of programs to the values of some known inputs), in the form of binding-time improvements, in order to bring known values closer together, to allow code simplifications  [14]. Namjoshi and Pavlinovic have more generally studied and formalized the impact of program transformations on program analysis  [20] , considering both positive and negative impacts on precision. AppEvolve is part of a line of research that has recently been attracting increasing interest on inferring program transformations from one or more examples. Some that could potentially benefit from our mitigation include LASE  [18]  and REFAZER  [24].
LASE  [18]  creates an edit script from common changes in a set of examples, locates the edit locations in a target application, and does the code transformation automatically. However, LASE is only able to abstract variable, method and type names, and thus it will never consider a method invocation with a simple variable as an argument to be the same as a method invocation where the argument is a more complex expression. Thus, it could potentially benefit from our mitigation. REFAZER  [24]  learns rewrite rules from change examples provided by the user. Rewrite rules use some information about the change context to determine whether a rule should be applied, which can limit rule applicability when a deprecated API is used in different contexts. Applying our mitigation to the context could reduce the diversity and increase the rule applicability.
VIII. CONCLUSION AND FUTURE WORK AppEvolve is the state-of-the-art approach for automatic update of deprecated-API usage in Android apps. Experiments previously reported for AppEvolve have shown that it can generate applicable updates for 85% of these API changes and 90% of their usage locations on mobile apps in the AppEvolve dataset. In this work, we evaluate whether this observed effectiveness is generalizable. We add 54 additional mobile apps that use the APIs contained in the AppEvolve dataset. Running AppEvolve on these mobile apps shows that AppEvolve fails to generate applicable updates for 81% of the mobile apps. By analyzing these failed cases, we found that they failed mainly due to: 1) Statements in the examples and at the target location are structurally different. 2) Object and arguments of the deprecated API method are in the form of complex expressions.
5) No examples found in GitHub. We mitigate the first and the second categories by performing a simple refactoring that modifies the code containing API usage in the target app to resemble the one in the example. Our mitigations enable AppEvolve to generate applicable updates for 86% of the failed cases. To try to resolve the discrepancy in the findings, we looked closer at the examples and target apps used by finding the original examples and target apps. We found that they were transformed analogous to our mitigation. These transformations convert invocations in various contexts into code exploitable by AppEvolve. Based on our findings, we propose future directions for automatic update of deprecated-API usage in Android apps, which include code normalization to ensure that both the example of API usage and the target app code are in the same standard form to minimize the variety of ways that the code is written.
public class TestMediaPlayer extends MediaPlayer { public TestMediaPlayer() { setAudioStreamType(AudioManager. STREAM_MUSIC); } public TestMediaPlayer(Context testContext , int withResource) throws Exception { this(); AssetFileDescriptor afd = testContext. getResources(). openRawResourceFd(withResource); assertNotNull(afd); setDataSource(afd. getFileDescriptor(), afd. getStartOffset(),afd. getLength()); afd. close(); prepare(); } } 5) No examples. No example illustrating the API update can be found in GitHub. 6) Others. These include cases that cannot be put to any category above. • Inheritance: The code below uses the deprecated API method setAudioStreamType of the class MediaPlayer. In the code snippet, TestMedia-Player extends MediaPlayer and thus it inherits the setAudioStreamType method.