arXiv subjects

Yoshiki Higo

Publications and source records attributed to Yoshiki Higo.

10 recordsLinked to original sources

arXiv2026

Cross-Ecosystem Packages As Multilingual: Prevalence, Architecture, and Health

Modern software development increasingly relies on using multiple programming languages. Some software packages are published to multiple package ecosystems such as NPM for JavaScript and PyPI for Python. Little is known about cross-ecosystem packages, especially regarding how they are structured. In this paper, we conduct a large-scale empirical study of over six million packages across six major ecosystems to understand 1) how prevalent cross-ecosystem packages are among all packages, 2) whether there are distinct source code architectural patterns that cross-ecosystem packages use, and 3) whether there are correlations between architectural patterns and project health metrics from GitHub. Results indicate that cross-ecosystem packages constitute a small but important, growing fraction of packages. We identify five distinct architectural patterns. For example, packages that implement code generation from a shared source file or use language bindings are associated with significantly higher community visibility and development activity. Based on our findings, we provide implications for package adopters, maintainers, and researchers. We envision our taxonomy being used for future investigations into several aspects of software development, such as the trade-offs between focusing on one language and translating to other languages using bindings, templating, and wrappers, versus using native code and native functions to support additional languages.

cs.SE↗

arXiv2026

Agent ATO: Visualizing Agent Interaction Timelines from Logs

AI coding agents are becoming part of developers' workflows, but their behavior is difficult to understand from final code changes alone. During a task, agents interact with software repositories through sequences of actions such as searching for files, reading code, editing programs, and running tests or build commands. These interactions, together with token usage, are often recorded in console logs, but raw logs are difficult for developers to inspect. In this paper, we propose Agent ATO (Agentic Trajectory Observer), a tool for visualizing AI coding agent interaction timelines from console logs. Agent ATO extracts agent interactions, classifies them by command or tool type, and visualizes them as timelines. In addition to an all-interaction timeline, Agent ATO provides filtered timelines that emphasize file discovery, file reading, file editing, and execution while preserving surrounding context. We illustrate how Agent ATO may help developers inspect and compare agent actions using selected runs from two repair tasks. Future work will apply Agent ATO to more agents, tasks, and development environments, and will evaluate whether it reduces the effort needed to compare trajectories.

cs.SE↗

arXiv2026

Why Are Agentic Pull Requests Merged or Rejected? An Empirical Study

AI coding agents increasingly submit pull requests (Agentic-PRs) to open-source repositories, yet their performance is commonly assessed using merge and rejection outcomes alone. We hypothesized that these outcome labels do not reliably reflect agent capability without considering review interactions. To test this, we conducted a decision-oriented analysis of 11,048 closed Agentic Pull Requests, refined to 9,799 human-reviewed PRs, and manually inspected 717 representative cases to recover decision rationale from interaction artifacts. We found that rejection outcomes substantially overstate agent error: only 35.7% of rejected PRs reflected clear agentic failures, while 31.2% were driven by workflow constraints and 33.1% lacked observable decision rationale. Among merged PRs, 15.4% required explicit reviewer involvement through feedback or direct commits, and 5.5% showed no visible interaction trace. We further observed systematic differences across agents, with Copilot and Devin more often embedded in reviewer-mediated workflows, while Codex and Cursor PRs were typically merged with minimal interaction. These results reject the assumption that PR outcomes alone capture agent performance and demonstrate the need for interaction-aware evaluation grounded in review behavior.

cs.SE↗

arXiv2026

Leveraging Mutation Analysis for LLM-based Repair of Quantum Programs

In recent years, Automated Program Repair (APR) techniques specifically designed for quantum programs have been proposed. However, existing approaches often suffer from low repair success rates or poor understandability of the generated patches. In this study, we construct a framework in which a large language model (LLM) generates code repairs along with a natural language explanation of the applied repairs. To investigate how the contextual information included in prompts influences APR performance for quantum programs, we design four prompt configurations with different combinations of static information, dynamic information, and mutation analysis results. Mutation analysis evaluates how small changes to specific parts of a program affect its execution results and provides more detailed dynamic information than simple execution outputs such as stack traces. Our experimental results show that mutation analysis can provide valuable contextual information for LLM-based APR of quantum programs, improving repair success rates (achieving 94.4% in our experiment) and in some cases also improving the quality of generated explanations. Our findings point toward new directions for developing APR techniques for quantum programs that enhance both reliability and explainability.

cs.SE↗

arXiv2025

Code Clone Refactoring in C# with Lambda Expressions

"Extract Method" refactoring is a technique for consolidating code clones. Parameterization approaches are used to extract a single method from multiple code clones that contain differences. This approach parameterizes expressions and behaviors within a method. In particular, behavior parameterization has been extensively studied in Java programs, but little research has been conducted on other programming languages. Lambda expressions can be used to parameterize behaviors, but the specifications of each programming language significantly affect the applicability of this technique. Therefore, the optimal "Extract Method" approach may vary depending on the programming language. In this study, we propose a C#-specific technique that uses lambda expressions to analyze and consolidate code clones. We evaluated our proposed method by applying it to code clones detected by the NiCad clone detector and measuring how many of them could be successfully consolidated. In total, 2,217 clone pairs from 22 projects were included in our evaluation. For the clone pairs determined to be refactorable, we also attempted refactoring actually. The proposed approach determined that 35.0% of all clone pairs were suitable for refactoring. Among these, 28.9% were successfully refactored.

cs.SE↗

arXiv2025

Coverage Isn't Enough: SBFL-Driven Insights into Manually Created vs. Automatically Generated Tests

The testing phase is an essential part of software development, but manually creating test cases can be time-consuming. Consequently, there is a growing need for more efficient testing methods. To reduce the burden on developers, various automated test generation tools have been developed, and several studies have been conducted to evaluate the effectiveness of the tests they produce. However, most of these studies focus primarily on coverage metrics, and only a few examine how well the tests support fault localization-particularly using artificial faults introduced through mutation testing. In this study, we compare the SBFL (Spectrum-Based Fault Localization) score and code coverage of automatically generated tests with those of manually created tests. The SBFL score indicates how accurately faults can be localized using SBFL techniques. By employing SBFL score as an evaluation metric-an approach rarely used in prior studies on test generation-we aim to provide new insights into the respective strengths and weaknesses of manually created and automatically generated tests. Our experimental results show that automatically generated tests achieve higher branch coverage than manually created tests, but their SBFL score is lower, especially for code with deeply nested structures. These findings offer guidance on how to effectively combine automatically generated and manually created testing approaches.

cs.SE↗

arXiv2025

A Dataset of Software Bill of Materials for Evaluating SBOM Consumption Tools

A Software Bill of Materials (SBOM) is becoming an essential tool for effective software dependency management. An SBOM is a list of components used in software, including details such as component names, versions, and licenses. Using SBOMs, developers can quickly identify software components and assess whether their software depends on vulnerable libraries. Numerous tools support software dependency management through SBOMs, which can be broadly categorized into two types: tools that generate SBOMs and tools that utilize SBOMs. A substantial collection of accurate SBOMs is required to evaluate tools that utilize SBOMs. However, there is no publicly available dataset specifically designed for this purpose, and research on SBOM consumption tools remains limited. In this paper, we present a dataset of SBOMs to address this gap. The dataset we constructed comprises 46 SBOMs generated from real-world Java projects, with plans to expand it to include a broader range of projects across various programming languages. Accurate and well-structured SBOMs enable researchers to evaluate the functionality of SBOM consumption tools and identify potential issues. We collected 3,271 Java projects from GitHub and generated SBOMs for 798 of them using Maven with an open-source SBOM generation tool. These SBOMs were refined through both automatic and manual corrections to ensure accuracy, currently resulting in 46 SBOMs that comply with the SPDX Lite profile, which defines minimal requirements tailored to practical workflows in industries. This process also revealed issues with the SBOM generation tools themselves. The dataset is publicly available on Zenodo (DOI: 10.5281/zenodo.14233415).

cs.SE↗

arXiv2025

SBOM Challenges for Developers: From Analysis of Stack Overflow Questions

Current software development takes advantage of many external libraries, but it entails security and copyright risks. While the use of the Software Bill of Materials (SBOM) has been encouraged to cope with this problem, its adoption is still insufficient. In this research, we analyzed the challenges that developers faced in practicing SBOM use by examining questions about SBOM utilization on Stack Overflow, a Q&A site for developers. As a result, we found that (1) the proportion of resolved questions about SBOM use is 15.0% which is extremely low, (2) the number of new questions has increased steadily from 2020 to 2023, and (3) SBOM users have three major challenges on SBOM tools.

cs.SE↗

arXiv2020

Ammonia: An Approach for Deriving Project-specific Bug Patterns

Finding and fixing buggy code is an important and cost-intensive maintenance task, and static analysis (SA) is one of the methods developers use to perform it. SA tools warn developers about potential bugs by scanning their source code for commonly occurring bug patterns, thus giving those developers opportunities to fix the warnings (potential bugs) before they release the software. Typically, SA tools scan for general bug patterns that are common to any software project (such as null pointer dereference), and not for project specific patterns. However, past research has pointed to this lack of customizability as a severe limiting issue in SA. Accordingly, in this paper, we propose an approach called Ammonia, which is based on statically analyzing changes across the development history of a project, as a means to identify project-specific bug patterns. Furthermore, the bug patterns identified by our tool do not relate to just one developer or one specific commit, they reflect the project as a whole and compliment the warnings from other SA tools that identify general bug patterns. Herein, we report on the application of our implemented tool and approach to four Java projects: Ant, Camel, POI, and Wicket. The results obtained show that our tool could detect 19 project specific bug patterns across those four projects. Next, through manual analysis, we determined that six of those change patterns were actual bugs and submitted pull requests based on those bug patterns. As a result, five of the pull requests were merged.

cs.SE↗

arXiv2020

On Tracking Java Methods with Git Mechanisms

Method-level historical information is useful in research on mining software repositories such as fault-prone module detection or evolutionary coupling identification. An existing technique named Historage converts a Git repository of a Java project to a finer-grained one. In a finer-grained repository, each Java method exists as a single file. Treating Java methods as files has an advantage, which is that Java methods can be tracked with Git mechanisms. The biggest benefit of tracking methods with Git mechanisms is that it can easily connect with any other tools and techniques build on Git infrastructure. However, Historage's tracking has an issue of accuracy, especially on small methods. More concretely, in the case that a small method is renamed or moved to another class, Historage has a limited capability to track the method. In this paper, we propose a new technique, FinerGit, to improve the trackability of Java methods with Git mechanisms. We implement FinerGit as a system and apply it to 182 open source software projects, which include 1,768K methods in total. The experimental results show that our tool has a higher capability of tracking methods in the case that methods are renamed or moved to other classes.

cs.SE↗