Implementing correct method invocation is an important task for software developers. However, this is challenging work, since the structure of method invocation can be complicated. In this paper, we propose InvocMap, a code completion tool allows developers to obtain an implementation of multiple method invocations from a list of method names inside code context. InvocMap is able to predict the nested method invocations which their names didn’t appear in the list of input method names given by developers. To achieve this, we analyze the Method Invocations by four levels of abstraction. We build a Machine Translation engine to learn the mapping from the first level to the third level of abstraction of multiple method invocations, which only requires developers to manually add local variables from generated expression to get the final code. We evaluate our proposed approach on six popular libraries: JDK, Android, GWT, Joda-Time, Hibernate, and Xstream. With the training corpus of 2.86 million method invocations extracted from 1000 Java Github projects and the testing corpus extracted from 120 online forums code snippets, InvocMap achieves the accuracy rate up to 84 in F1- score depending on how much information of context provided along with method names, that shows its potential for auto code completion. Writing code is a challenge for non-experienced software developers. To write the code that implements a specific task in a programming language, developers need to remember the syntax of that language and be familiar with how to implement method invocations. While the syntax of the language is easier to learn since it contains a permanent set of words in the vocabulary, implementing Method Invocations (MI)s is more challenging due to the following reasons. First of all, developers need to remember the structure and the combination of invocations depending on their purpose. Secondly, the implementation of method invocation is also depending on the surrounding context of the code. Thus, the code developed by non-experience developers may be in the risks of being semantic error. To help developers with interacting and analyzing by a given Java source code snippet, Java Development Tool (JDT) library defines a list of Abstract Syntax Tree (AST) Node types (Eclipse, 2019) . With the list of these AST Node types, JDT is able to interact with the structure of each elements inside the source code. MI, which is defined as sub-type of Expression, is one of the fundamental AST Nodes that developers need to implement. MI has been used to make Application Programming Interface (API) calls from other libraries or from other methods inside a Java project. The structure of a syntactically correct MI contains method name, receiver and the list of arguments which could be empty. Since receiver and arguments are types of expression (Eclipse, 2019) , the structure of an MI could be complicated as a deep AST tree. The reason for this issue is that expression can be composed by different types of AST Node including MI. An example of a complicated MI is shown in Listing 1. Within this Listing, the outside MI contains four nested MI in its implementation. Additionally, there are five positions that requires local variables inside the expression. Type casting to integer is embedded to this MI to provide a semantically correct MI. This MI is used along with other calculated MIs inside the body of method, providing the a specific surrounding context for this MI. Without doubt, the outer method name set is just one word while the respected MI is a deep AST tree. The representation of MI also relies on code context. Consider examples 2A and 2B on Listing 2 and Listing 3. These Listings show the implementation of API android.content.Intent.getBooleanExtra(). Although 2 MIs share the same information about context of using the same local variable Intent and the false boolean literal, they are differ in the structure of AST. Since the MI in Listing 2 associates with the action of add or remove an application package from an android device, the MI on Listing 3 associates with actions of network status checking. The difference in contexts brings 2 MIs, which represents in 2 static Field Accesses Intent.EXTRA REPLACING and ConnectivityManager.EXTRA NO CONNECTIVITY. Listing 1: Example in Android (2019a) 1 p u b l i c v o i d s e t O f f s e t s ( i n t n e w H o r i z o n t a l O f f s e t , i n t n e w V e r t i c a l O f f s e t ) { 2 . . . . . . 5 i n v a l i d a t e R e c t f . o f f s e t (− x o f f s e t , −y o f f s e t ) ; 6 i n v a l i d a t e R e c t . s e t ( ( i n t ) Math . f l o o r ( i n v a l i d a t e R e c t f . l e f t ) , ( i n t ) Math . f l o o r ( i n v a l i d a t e R e c t f . t o p ) , ( i n t ) Math . c e i l ( i n v a l i d a t e R e c t f . r i g h t ) , ( i n t ) Math . c e i l ( i n v a l i d a t e R e c t f . b o t t o m ) ) ; 7 . . . Listing 2: Example 2A in Android (2019b) 1 p u b l i c v o i d o n R e c e i v e ( C o n t e x t c o n t e x t , I n t e n t i n t e n t ) { 2 . . . 3 i f ( ( I n t e n t . ACTION PACKAGE REMOVED . e q u a l s ( a c t i o n ) | | 4 I n t e n t . ACTION PACKAGE 5 ADDED . e q u a l s ( a c t i o n ) ) 6 && ! i n t e n t . g e t B o o l e a n E x t r a ( I n t e n t . EXTRA REPLACING , f a l s e ) ) { 7 . . . Listing 3: Example 2B in Android (2019c) 1 p u b l i c v o i d o n R e c e i v e ( C o n t e x t c o n t e x t , I n t e n t i n t e n t ) { 2 . . . 3 i f ( a c t i v e N e t w o r k == n u l l ) { 4 . . . 5 } e l s e i f ( a c t i v e N e t w o r k . g e t T y p e ( ) == n e t w o r k T y p e ) { 6 mNetworkUnmetered = f a l s e ; 7 mNetworkConnected = ! i n t e n t . g e t B o o l e a n E x t r a ( C o n n e c t i v i t y M a n a g e r . EXTRA NO CONNECTIVITY , f a l s e ) ; 8 . . . From the examples above, we recognize that implementing an effective method invocation requires strong background and experiences of developers. Even two MIs that belong to the same API and share the same context of local variables and literal still have ambiguous in the way of implementation like Listing 2 and Listing 3. These challenges hinders the ability of writing a appropriate MI and as well as developers need to spend time to remember or identify the correct structure of AST in MI for software development. With this work, we want to tackle this problem by providing InvocMap, a code completion tool for helping developers to achieve the implementation of method invocation efficiently. InvocMap accepts input as a sequence of method names inside the code environment of a method declaration, then produce the output as the list of ASTs as translation results for each input method names. The generated ASTs will only require developers to input information about local variables and literals in order to obtain the complete code. For instance, in Listing 2, developer can write the list of method names including the name getBooleanExtra. The output for the suggestion will be #.getBooleanExtra ( Intent.EXTRA REPLACING,#), which can be completed manually by a variable of type android.content.Intent in the first "#" and a boolean literal in the second "#". Statistical Machine Translation (SMT) is a well-known approach in Natural Language Processing (NLP) for translating between languages (Green et al., 2014) . For taking advantage from SMT, we propose a direction of code completion for Method Invocation by a Statistical approach, which learn the translation from the abstract information of MIs to the their detail information, which are represented by AST with complicate structure. First and foremost, we analyze the information inside a typical MI. We divide the MI by four levels of abstraction. We also define information of context for each MI which can help to predict the AST structure. Next, we build an SMT engine specified for our work to infer from the very abstract layer of MI, means Method Name, to the third level of MI, which is an AST tree that requires to be fulfill by local variables and literals. In order to evaluate our approach, we do experiments to check the accuracy of our code completion technique in two data sets collected from Github and from online forums. Resources of this paper can be found in (InvocMap, 2019) . This research has following contributions: 2. Designing rules for extracting code tokens for representing abstract level and details level for various types of AST nodes. 3. Proposing an algorithm for visiting a method invocation inside the code environment to abstract and encode their structure in AST as an object for statistical learning. 4. Building a SMT system for learning from the context of code environment, including MIs from large scale Github high quality projects. This SMT system is able to predict the sequences of AST structure given sequences of method name and context. In this work, we proposed InvocMap, a SMT engine for inferring the ASTs of method invocations from a list of method names and code context. By the evaluation on corpus collected from Github projects and online forums, we demonstrated the potential of our approach for auto code completion. A major advantage of InvocMap is that it is built on the idea of abstracting method invocations by four different levels. We provided an algorithm to achieve AST of method invocations for the method invocations inference. As future works, we will work on extending the SMT model to support inputs from multiple natural language descriptions of multiple method invocations, along with investigation of machine learning techniques for improving the accuracy.
This paper proposes a theory of classifying Method Invocations by different abstraction levels and conducting a statistical approach for code completion from method name to method invocation.
{"src": "scitldr-AIC_train", "paper_id": "BJxOZ04Kvr"}