275 lines
20 KiB
Markdown
275 lines
20 KiB
Markdown
tags:: [[#zotero]]
|
||
date:: 2026
|
||
title:: @Recommending Relevant Classes for Infrequent API Classes
|
||
item-type:: [[journalArticle]]
|
||
original-title:: Recommending Relevant Classes for Infrequent API Classes
|
||
language:: en
|
||
authors:: [[Anonymous Author]]
|
||
library-catalog:: Zotero
|
||
links:: [Local library](zotero://select/library/items/9I4Q6XAZ), [Web library](https://www.zotero.org/users/1039502/items/9I4Q6XAZ)
|
||
|
||
- [[Abstract]]
|
||
- Although libraries (e.g., J2SE) provide many reusable Application Programming Interfaces (APIs) and are widely used, calling an API class often implements only simple functionalities. As there are many API classes, it is challenging to identify relevant API classes for a given API class. For frequent API classes, various mining approaches, code search engines, and LLMs can help. However, more than 80% of API classes are infrequently called in real projects. The problem is inherent and relevant. If code samples are unavailable or too few, existing approaches are ineffective.
|
||
- ### Attachments
|
||
- [PDF](zotero://select/library/items/7PARQGX2) {{zotero-imported-file 7PARQGX2, "Author - 2026 - Recommending Relevant Classes for Infrequent API Classes.pdf"}}
|
||
- ### Notes
|
||
- I'm reviewing a research paper and I took the following notes:
|
||
|
||
# Annotations
|
||
(17/09/2025, 11:44:16)
|
||
|
||
- “Although libraries (e.g., J2SE) provide many reusable Application Programming Interfaces (APIs) and are widely used, calling an API class often implements only simple functionalities.” (Author, 2026, p. 1) #5fb236
|
||
|
||
- “As there are many API classes, it is challenging to identify relevant API classes for a given API class.” (Author, 2026, p. 1) #ffd400
|
||
*Bad written. Not clear.*
|
||
|
||
- “However, more than 80% of API classes are infrequently called in real projects.” (Author, 2026, p. 1) #e56eee
|
||
|
||
- “If code samples are unavailable or too few, existing approaches are ineffective.” (Author, 2026, p. 1) #e56eee
|
||
*We are referring bias issues here.*
|
||
|
||
- “APIrel, can predict relevant classes, even if such patterns do not appear in documents or source files.” (Author, 2026, p. 1) #a28ae5
|
||
|
||
- “APIrel uses mined patterns as seeds and compares API documents to build labeled data.” (Author, 2026, p. 1) #ffd400
|
||
*What is mined? When?*
|
||
|
||
- “Based on labeled data, APIrel then builds a model by observing the documents of API classes with and without patterns” (Author, 2026, p. 1) #a28ae5
|
||
|
||
- “Given the documents of two API classes, our trained model can predict whether they are relevant.” (Author, 2026, p. 1) #ffd400
|
||
*For what? What kind of documents are given as input?*
|
||
|
||
- “As introduced in Section 7,” (Author, 2026, p. 1) #ffd400
|
||
*It's a too far forward reference.*
|
||
|
||
- “inferring from documents” (Author, 2026, p. 1) #2ea8e5
|
||
|
||
- “mining from clients.” (Author, 2026, p. 1) #2ea8e5
|
||
|
||
- “As specifications define the rules of calling APIs, it is feasible to identify relevant API classes from mined specifications. However, both research lines have inherent limitations” (Author, 2026, p. 1) #ffd400
|
||
|
||
- “s.F” (Author, 2026, p. 1) #ff6666
|
||
|
||
- “a templates” (Author, 2026, p. 1) #ff6666
|
||
|
||
- “For instance, API documents rarely mention relevant API classes, especially when such classes are infrequent.” (Author, 2026, p. 1) #ffd400
|
||
*Sentences like this require some examples, they are not clear!!*
|
||
|
||
- “As a result, the prior approaches are unlikely to infer many relevant infrequent API classes from documents. The limitation is inherent.” (Author, 2026, p. 1) #ffd400
|
||
*Can you show some explanatory example?*
|
||
|
||
- “For instance, researchers use Apriori algorithms to mine the relevant libraries.” (Author, 2026, p. 1) #ffd400
|
||
*This is not clear.*
|
||
|
||
- “They report that only LibSeek [31] can recommend relevant infrequent libraries, but its effectiveness is unsatisfactory. In particular, its precision and recall are only 21.1% and 69.4% in the best scenario, and they drop to 3.1% and 0.9% in the worst scenario.” (Author, 2026, p. 1) #5fb236
|
||
|
||
- “95% of API classes are called by less than 10% of clients,” (Author, 2026, p. 1) #a28ae5
|
||
|
||
- “hiding 88% of API classes do not affect 75% of clients.” (Author, 2026, p. 1) #a28ae5
|
||
|
||
- “As most API classes are infrequent, existing approaches can work for only a small set of frequent API classes.” (Author, 2026, p. 1) #e56eee
|
||
|
||
- “APIrel. It is the first approach that infers relevant classes from documents without predefined templates.” (Author, 2026, p. 1) #ffd400
|
||
*What kind of documents? We are almost at the end of the introduction and this is not clear.*
|
||
|
||
- “Although most API classes are infrequent, it is feasible to mine some specifications from clients. We use them as the seeds to infer more rules. Although documents seldom explicitly define rules, e.g., relevant classes, API documentations provide documents for most APIs” (Author, 2026, p. 1) #ffd400
|
||
*What kind of rules are referring to?*
|
||
|
||
- “In our new direction, we mine seen API patterns from source files and use such patterns to label data” (Author, 2026, p. 1) #ffd400
|
||
*Why is this different from existing approaches?*
|
||
|
||
- “predicted relevant API class” (Author, 2026, p. 2) #ffd400
|
||
*How is the prediction done? What does the prediction, when?*
|
||
|
||
- “API” (Author, 2026, p. 2) #ffd400
|
||
|
||
- “can train a model to predict unseen patterns based on a small portion of frequent API classes” (Author, 2026, p. 2) #ffd400
|
||
*This is obscure!*
|
||
|
||
- “Given the documents of two API classes, the trained model predicts whether they are relevant.” (Author, 2026, p. 2) #ffd400
|
||
*For what?*
|
||
|
||
- “popular API classes, we conduct a tenfold cross-validation. In each fold, the training set provides API documents and the labels to train a model, and the testing set feeds API documents to the trained model. As the trained model takes only API documents as its input, it works for new API classes without any samples. The f-score values of our prediction vary from 70% to 80%.” (Author, 2026, p. 2) #ffd400
|
||
*Not clear!*
|
||
|
||
- “https://anonymous.4open.science/r/apirel.” (Author, 2026, p. 2) #ffd400
|
||
*Tried to visit the link but the following message is obtained while trying to access the content:
|
||
"The requested file is not found."*
|
||
|
||
- “2 ILLUSTRATING EXAMPLE” (Author, 2026, p. 2) #ffd400
|
||
*The paper should be improved by clearly distinguishing the presentation of the problem to be solved and the proposed solution. These are mixed in many parts of the paper, which is not effective in presenting the problem and the limitations of existing approaches. Unfortunately, the motivation part of the paper relies on some examples based on the SearchCode system, which seems is no longer active and online.*
|
||
|
||
- “the document of HSSFWorkbook.” (Author, 2026, p. 2) #ffd400
|
||
*The document?*
|
||
|
||
- “From the clients” (Author, 2026, p. 2) #ffd400
|
||
*What's the client you are referring to?*
|
||
|
||
- “HSSFSheet is frequently called with HSSFWorkbook.” (Author, 2026, p. 2) #ffd400
|
||
*How can you see that from Fig. 1?*
|
||
|
||
- ““See Also” titles often ignore many relevant APIs, since it takes too much effort to manually write all of them.” (Author, 2026, p. 2) #5fb236
|
||
|
||
- “Many mined relevant classes are not defined in documents” (Author, 2026, p. 2) #a28ae5
|
||
|
||
- “Using these instances as its training data, APIrel builds a classification model that can predict unseen API patterns.” (Author, 2026, p. 2) #5fb236
|
||
|
||
- “prior approaches” (Author, 2026, p. 2) #ffd400
|
||
*which one?*
|
||
|
||
- “As a comparison, the prior approaches can mine relevant classes only for frequent APIs. In Section 4, we split the labeled instances into ten groups. In each fold, we use nine groups to train our model, and use the remaining group to test our model. We switch the testing group, and test our model for all possible labels. The results show that APIrel achieves around 70% f-score values even if it infers from only documents. APIrel can infe” (Author, 2026, p. 2) #ffd400
|
||
*This is something related to the evaluation. WHy mentioning here at section 2 of the paper when the details of the approach are not given yet?*
|
||
|
||
- “it infers that HSSFBorderFormatting and HSSFWorkbook are relevant” (Author, 2026, p. 2) #ffd400
|
||
*with respect to what? How relevance is assessed?
|
||
How is relevance defined?*
|
||
|
||
- “SearchCode” (Author, 2026, p. 2) #ffd400
|
||
*No longer available.*
|
||
|
||
- “Although the two API classes are relevant, the prior approaches are unlikely to infer this pattern since its code samples are too few.” (Author, 2026, p. 2) #ffd400
|
||
|
||
- “It is infeasible for the prior approaches to mine patterns from only one observation.” (Author, 2026, p. 2) #5fb236
|
||
|
||
- “Table 3 s” (Author, 2026, p. 2) #ffd400
|
||
*It should be Table 1*
|
||
|
||
- “To handle the problem, from each code sample of a library, our tool extracts all its called API classes and methods, and removes samples whose called classes or methods are not declared by the latest versions.” (Author, 2026, p. 2) #ffd400
|
||
*When it extracts? What does it mean?*
|
||
|
||
- “A small set of API classes are intensively called by most clients, while most API classes are used by less than 10% of clients. Based on the findings, a learning-based approach can work for only a few critical frequent APIs.” (Author, 2026, p. 3) #5fb236
|
||
|
||
- “However, if we use the mined patterns as labels, we can train models that work for many more APIs” (Author, 2026, p. 3) #ffd400
|
||
*This is not clear!*
|
||
|
||
- “Definition 1. The relevant API classes of an API class are classes that can be called together to implement functionalities.” (Author, 2026, p. 3) #ffd400
|
||
*What does it mean "called together"? What does it mean call a class?*
|
||
|
||
- “As infrequent APIs have documents, it is feasible to infer relevant classes for infrequent APIs.” (Author, 2026, p. 3) #ffd400
|
||
*What does it mean that infrequent APIs have documents? Also the second part of the sentence is not clear to me.*
|
||
|
||
- “To infer hidden patterns, we reduce the inference of infrequent relevant API classes into a classification problem. For example, taking the documents of two classes (d1 and d2) as inputs, a solution to our problem is to train a model, f (d1, d2) ⇝ l, that predicts whether d1 and d2 are relevant. After paired API classes are predicted, they can be merged into larger sets” (Author, 2026, p. 3) #ffd400
|
||
*Paragraphs like this require some explanatory example. It's not clear what do you want to do in practice here.*
|
||
|
||
- “As API documents seldom mention relevant classes, it is quite challenging to construct the labels from documents.” (Author, 2026, p. 3) #ffd400
|
||
|
||
- “To handle the problem, we use mined patterns as the gold standard, and propose a new research direction that infers unknown knowledge from known knowledge.” (Author, 2026, p. 3) #ffd400
|
||
*mmmmmm can you give some examples? This is very vague!*
|
||
|
||
- “, our tool uses its full name to build the query.” (Author, 2026, p. 3) #ffd400
|
||
*"Our tool" which tool, when is the query created? How is the tool supposed to be installed/used/....
|
||
|
||
The paper requires a serious revision to improve the presentation and the writing in general.*
|
||
|
||
- “PPA [19] is a library for analyzing partial code, and we build APIrel on PPA. After the trees are built, APIrel traverses them to collect the called API classes of each method. Our tool collects the full list of API classes for each library. For each method, APIrel extracts its directly dependent API classes (e.g., API classes in cast expressions), and its indirectly dependent API classes (e.g., resolving the types of variables). APIrel merges the two sets of classes to build the used API classes of a method.” (Author, 2026, p. 3) #ffd400
|
||
*I think some parts of the paper can be reduced to gain some space to be used for presenting some examples to explain technical sentences like these ones.*
|
||
|
||
- “Table 2: Our features” (Author, 2026, p. 4) #ffd400
|
||
*It should be moved to sec 3.*
|
||
|
||
- “A transaction database, T DB, is a set of transactions. Given a transaction database T DB, the support of an itemset X , denoted as sup (X ), is the number of transactions in T DB that contain X . An itemset X is a closed itemset, if there exists no itemset X ′ such that (1) X ′ is a proper superset of X , and (2) if a transaction contains X , it also contains X ′.” (Author, 2026, p. 4) #ffd400
|
||
*Example is needed otherwise this is unreadable.*
|
||
|
||
- “itemset contains the API classes that are frequently called in a method.” (Author, 2026, p. 4) #e56eee
|
||
|
||
- “APIrel mines that CellStyle, HSSFSheet, and HSSFWorkbook are frequently called in a method. Many API classes are less popular and do not appear in collected source files. As Yen et al. [70] mine frequent itemsets, their approach cannot mine unseen relevant API classes, and their mined API patterns cover only a small set of API classes.” (Author, 2026, p. 4) #ffd400
|
||
*OK, I can start from this. The rest is still obscure to me. I hope the next sections clarify.*
|
||
|
||
- “comparing mined API patterns with API documents (Section 3.3.1), and trains a classification model” (Author, 2026, p. 4) #5fb236
|
||
|
||
- “3.3.1 Extracting positive and negative instances” (Author, 2026, p. 4) #2ea8e5
|
||
|
||
- “Line 1 builds a dictionary from mined patterns. This dictionary contains all the API classes that appear in SET .” (Author, 2026, p. 4) #ffd400
|
||
*Can you make some concrete examples by referring to the running motivating example?*
|
||
|
||
- “Line 6 checks whether the c1 and c2 classes appear in our dictionary. If one of them does not appear in the dictionary, we conclude that their patterns cannot be observed from the mined API patterns.” (Author, 2026, p. 4) #ffd400
|
||
*This step requires more elaboration by referring to the motivating example shown in Figure 1.*
|
||
|
||
- “Feature 1. The number of overlapped verbs and nouns in class descriptions.” (Author, 2026, p. 4) #2ea8e5
|
||
|
||
- “Feature 2. The frequencies of class names.” (Author, 2026, p. 4) #2ea8e5
|
||
|
||
- “Feature 3. The distance between two classes in their super types.” (Author, 2026, p. 4) #2ea8e5
|
||
|
||
- “Feature 4. The number of overlapped interfaces.” (Author, 2026, p. 4) #2ea8e5
|
||
|
||
- “Feature 5. The number of overlapped subclasses.” (Author, 2026, p. 4) #2ea8e5
|
||
|
||
- “Feature 6. The number of overlapped references.” (Author, 2026, p. 4) #2ea8e5
|
||
|
||
- “Feature 7. The number of fields whose type is the other class.” (Author, 2026, p. 5) #2ea8e5
|
||
|
||
- “Feature 8. The links of method parameters.” (Author, 2026, p. 5) #2ea8e5
|
||
|
||
- “Feature 9. The number of methods whose return type is the other class.” (Author, 2026, p. 5) #2ea8e5
|
||
|
||
- “Feature 10. The frequencies of the other class name in a method description.” (Author, 2026, p. 5) #2ea8e5
|
||
|
||
- “Feature 11. The frequencies of the other class name in the thrown exceptions from the methods of a class.” (Author, 2026, p. 5) #2ea8e5
|
||
|
||
- “Feature 12. The number of methods that refer to the other class.” (Author, 2026, p. 5) #2ea8e5
|
||
|
||
- “Feature 13. The number of methods that are specified in the other class.” (Author, 2026, p. 5) #2ea8e5
|
||
|
||
- “Feature 14. The links of constructor parameters.” (Author, 2026, p. 5) #2ea8e5
|
||
|
||
- “4 EVALUATION ON CORRECTNESS This section explores the he following RQs: (RQ1) How accurate are our approach (Section 4.3)? (RQ2) What are the key features (Section 4.4)? (RQ3) What is the impact of labels (Section 4.5)?” (Author, 2026, p. 6) #ffd400
|
||
*The main problem that I had so far with the previous section is about presentation. The paper is not effective in presenting the problems and the solution. Many sentences are unclear and I had to go through them to try catching the meaning or the technical details that should be made explicit by referring for instance to a running example.
|
||
|
||
Let's see if the Evaluation improves the situation.....*
|
||
|
||
- “API documents in Table 3” (Author, 2026, p. 6) #ffd400
|
||
*This is not clear. Table 3 list the same labries listed in table 4 and does not include API documents.*
|
||
|
||
- “All the libraries are shipped with their API documents.” (Author, 2026, p. 6) #5fb236
|
||
|
||
- “The repository of SearchCode has millions of projects. By default, SearchCode retrieves 100 samples per page. Each sample is a source file that calls the queried API. For some popular API classes, it retrieves thousands of pages. As it is impractical to download all samples, we limit the analysis scope of our tool to the top 20 pages, i.e., the top 2,000 samples per API class.” (Author, 2026, p. 6) #ffd400
|
||
*What's the role of SeachCode in this paragraph*
|
||
|
||
- “4.2 No Baseline Statement” (Author, 2026, p. 6) #ffd400
|
||
*This seems to be an appendix of the related work section, why not merging this with the related work section and move after the introduction by extending with some motivating examples clearly presenting all the different concepts and motivating the paper?*
|
||
|
||
- “As introduced in Section 7,” (Author, 2026, p. 6) #ffd400
|
||
*Since it is referred many times in previous sections, why not moving section 7 after the introduction section.*
|
||
|
||
- “The first line of approaches analyzes documents with templates. As documents rarely mention relevant classes, these approaches may not infer many relevant classes. We do not compare with them since the improvement is explicit. The second line of approaches mines relevant classes from clients.” (Author, 2026, p. 6) #ffd400
|
||
*The distinction between document analysis and clients should make more clear by means of some explanatory examples.*
|
||
|
||
- “The accuracy” (Author, 2026, p. 7) #ffd400
|
||
*it's not clear what this accuracy is about. Is it on the capability of the approach of detecting relevant classes? I think human in the loop should be considered.*
|
||
|
||
- “Predicting more complicated infrequent API patterns” (Author, 2026, p. 9) #5fb236
|
||
|
||
- “To improve the completeness of API patterns, in this paper, we propose a new direction for inferring infrequent API patterns.” (Author, 2026, p. 10) #5fb236
|
||
|
||
- “Our basic idea is to learn a model from API documents and already mined frequent patterns. Mimicking how programmers infer from documents, we proposed APIrel to infer relevant API classes for long-tail and new APIs.” (Author, 2026, p. 10) #5fb236
|
||
|
||
- “We evaluated APIrel on five popular libraries. Our results show that our predicted unseen relevant classes are reasonably accurate (fscores around 80%). Based on our positive results, our new direction has the potential to be extended for predicting more complicated API patterns.” (Author, 2026, p. 10) #ffd400
|
||
*I think it is necessary to revise the evaluation by involving developers!*
|
||
|
||
COnsider that those that are tagget with #5fb236 are just highlights, those that are tagged with #e56eee and #a28ae5 are imporant sentences. Please pay attention instead to the notes that are tagged with #ffd400. Those that are tagged with #ff6666 are typos or errors. Could you please draft a review by organizing it as follows:
|
||
|
||
SUMMARY: Just a few sentence to summarize the work
|
||
|
||
STRENGHTS:
|
||
|
||
WEAKNESSES:
|
||
|
||
COMMENTS: Organize the notes with respect to the following criteria:
|
||
|
||
-
|
||
`Novelty`
|
||
|
||
-
|
||
`Rigor`
|
||
|
||
-
|
||
`Relevance (of the contribution)`
|
||
|
||
-
|
||
`Verifiability and Transparency`
|
||
|
||
-
|
||
`Presentation`
|
||
|
||
And then add a Detailed Comments section to report the notes that contain issues or typos.
|
||
Can you also formulate three explicit questions by considering the comments above? |