Apache Projects Research Articles

Deep semi-supervised learning for recovering traceability links between issues and commits

Traceability links between issues and commits record valuable information about the evolutionary history of software projects. Unfortunately, these links are often missing. While deep learning stands as the current state-of-the-art (SOTA) in automated traceability links recovery (TLR), its effectiveness is faced with the practical problem of limited labeled data during training. To overcome this challenge, in this paper, we propose DSSLink, a novel method based on deep semi-supervised learning, enhancing deep-learning-based link recovery tasks. DSSLink first learns knowledge from labeled data through pre-trained model and then leverages deep semi-supervised learning to infer pseudo-labels on unlabeled data. The extended dataset of pseudo-labeled and labeled data re-trains the deep learning model in an iterative process. Our extensive evaluations are conducted on two SOTA traceability methods (T-BERT and BTLink) across four GitHub projects and 11 Apache projects. Specifically, the maximum F1-score improvements for GitHub and Apache projects reached 22.9% and 43.5%, respectively. Evaluation results show that DSSLink is effective in enhancing TLR performance and outperforms TraceFUN, a recent approach that utilizes unlabeled data for TLR. The source code of DSSLink is available at https://github.com/DSSLink.Editor’s note: Open Science material was validated by the Journal of Systems and Software Open Science Board.

An empirical study on the usage of mocking frameworks in Apache software foundation

Mocking frameworks provide convenient APIs, which create mock objects, manipulate their behavior, and verify their execution, for the purpose of isolating test dependencies in unit testing. This study contributes an in-depth empirical study of whether and how mocking frameworks are used in Apache projects. The key findings and insights of this study include: First, mocking frameworks are widely used in 66% of Apache Java projects, with Mockito, EasyMock, and PowerMock being the top three most popular frameworks. Larger-scale and more recent projects tend to observe a stronger need to use mocking frameworks. This underscores the importance of mocking in practice and related future research. Second, mocking is overall practiced quite selectively in software projects—not all test files use mocking, nor all dependencies of a test target are mocked. It calls for more future research to gain a more systematic understanding of when and what to mock to provide formal guidance to practitioners. On top of this, the intensity of mocking in different projects shows different trends in the projects’ evolution history—implying the compound effects of various factors, such as the pace of a project’s growth, the available resources, time pressure, and priority, etc. This points to an important future research direction in facilitating best mocking practices in software evolution. Furthermore, we revealed the most frequently used APIs in the three most popular frameworks, organized based on the function types. The top five APIs in each functional type of the three mocking frameworks usually take the majority (78% to 100%) of usage in Apache projects. This indicates that developers can focus on these APIs to quickly learn the common usage of these mocking frameworks. We further investigated informal methods of mocking, which do not rely on any mocking framework. These informal mocking methods point to potential sub-optimal mocking practices that could be improved, as well as limitations of existing mocking frameworks. Finally, we conducted a developer survey to collect additional insights regarding the above analysis based on their experience, which complements our analysis based on repository mining. Overall, this study offers practitioners profound empirical knowledge of how mocking frameworks are used in practice and sheds light on future research directions to enhancing mocking in practice.

Summarization of Software Bug Report based on Sentence Semantic Similarity (SSBRSSS) Technique

In this work, sentence similarity between sentences of software bug report is computed. For this, two methods are utilized, Latent Semantic Analysis and Text Rank. Latent Semantic Analysis is used to compute semantic similarity between sentences of bug reports which infers deeper and hidden relation between words. From this, a pair of sentences with semantic similarity above a set threshold is selected and from one pair of sentences, only one sentence is selected. The remaining sentences are passed into TextRank algorithm and sentences with high similarity are further selected to generate a coherent summary. The proposed approach is evaluated on a newly constructed Apache Project Bug Report Corpus and existing Bug Report Corpus. The proposed approach is also compared with baseline approaches that mainly focus on only lexical similarity. The results when evaluated on Apache project Bug Report Corpus attains an average value of 80%, 72.57%, 76.05% and 76.57% in terms of precision, recall, F-score and pyramid precision respectively.

Secure CodeCity: 3-dimensional visualization of software security facets

Over the last few decades, the software industry investigated security best practices to guide software developers in producing less vulnerable software products. As a result, security engineering has emerged as an integral part of the software development lifecycle. With the increase in the number of security vulnerabilities discovered, the software industry encountered challenges finding software security experts. Despite the availability of static code analysis tools to detect security vulnerabilities, they are underused due to several reasons such as inadequate usability and the lack of integration support. For example, such tools are deficient in providing enough information, produce faulty warning messages, and miscommunicate with developers. As a solution, this work presents a conceptual framework and a proof-of-concept visualization tool, Secure CodeCity, as an extension to the CodeCity metaphor, to facilitate security analytics. Secure CodeCity extends the CodeCity metaphor into three different granularity levels in 3-dimensional space, facilitating the vulnerability analysis in different granularities. Thus, software practitioners can use Secure CodeCity to obtain useful security-related information such as "What is the most vulnerable class/method in a particular software project?". A between-subjects design-based user study was conducted with 23 subjects using a set of security-related tasks with two benchmark open-source Apache projects. The evaluation results show that Secure CodeCity surpasses the state-of-the-art security analysis tools in terms of correctness, usability, and time efficiency.

How do programmers fix bugs as workarounds? An empirical study on Apache projects

How do programmers fix bugs as workarounds? An empirical study on Apache projects

Just-in-time code duplicates extraction

Refactoring is a critical task in software maintenance, and is usually performed to enforce better design and coding practices, while coping with design defects. The Extract Method refactoring is widely used for merging duplicate code fragments into a single new method. Several studies attempted to recommend Extract Method refactoring opportunities using different techniques, including program slicing, program dependency graph analysis, change history analysis, structural similarity, and feature extraction. However, irrespective of the method, most of the existing approaches interfere with the developer’s workflow: they require the developer to stop coding and analyze the suggested opportunities, and also consider all refactoring suggestions in the entire project without focusing on the development context. To increase the adoption of the Extract Method refactoring, in this paper, we aim to investigate the effectiveness of machine learning and deep learning algorithms for its recommendation while maintaining the workflow of the developer. The proposed approach relies on mining prior applied Extract Method refactorings and extracting their features to train a deep learning classifier that detects them in the user’s code. We implemented our approach as a plugin for IntelliJ IDEA called AntiCopyPaster. To develop our approach, we trained and evaluated various popular models on a dataset of 18,942 code fragments from 13 Open Source Apache projects. The results show that the best model is the Convolutional Neural Network (CNN), which recommends appropriate Extract Method refactorings with an F-measure of 0.82. We also conducted a qualitative study with 72 developers to evaluate the usefulness of the developed plugin. The results show that developers tend to appreciate the idea of the approach and are satisfied with various aspects of the plugin’s operation.

Fault-insertion and fault-fixing behavioural patterns in Apache Software Foundation Projects

Developers inevitably make human errors while coding. These errors can lead to faults in code, some of which may result in system failures. It is important to reduce the faults inserted by developers as well as fix any that slip through. To investigate the fault insertion and fault fixing activities of developers. We identify developers who insert and fix faults, ask whether code topic ‘experts’ insert fewer faults, and experts fix more faults and whether patterns of insertion and fixing change over time. We perform a time-based analysis of developer activity on twelve Apache projects using Latent Dirichlet Allocation (LDA), Network Analysis and Topic Modelling. We also build three models (using Petri-net, Markov Chain and Hawkes Processes) which describe and simulate developers’ bug-introduction and fixing behaviour. We show that: the majority of the projects we analysed have developers who dominate in the insertion and fixing of faults; Faults are less likely to be inserted by developers with code topic expertise; Different projects have different patterns of fault inserting and fixing over time. We recommend that projects identify the code topic expertise of developers and use expertise information to inform the assignment of project work.

Studying the characteristics of SQL-related development tasks: An empirical study

A key function of a software system is its ability to facilitate the manipulation of data, which is often implemented using a flavour of the Structured Query Language (SQL). To develop the data operations of software (i.e, creating, retrieving, updating, and deleting data), developers are required to excel in writing and combining both SQL and application code. The problem is that writing SQL code in itself is already challenging (e.g., SQL anti-patterns are commonplace) and combining SQL with application code (i.e., for SQL development tasks) is even more demanding. Meanwhile, we have little empirical understanding regarding the characteristics of SQL development tasks. Do SQL development tasks typically need more code changes? Do they typically have a longer time-to-completion? Answers to such questions would prepare the community for the potential challenges associated with such tasks. Our results obtained from 20 Apache projects reveal that SQL development tasks have a significantly longer time-to-completion than SQL-unrelated tasks and require significantly more code changes. Through our qualitative analyses, we observe that SQL development tasks require more spread out changes, effort in reviews and documentation. Our results also corroborate previous research highlighting the prevalence of SQL anti-patterns. The software engineering community should make provision for the peculiarities of SQL coding, in the delivery of safe and secure interactive software.

Evaluation of Static Vulnerability Detection Tools With Java Cryptographic API Benchmarks

Several studies showed that misuses of cryptographic APIs are common in real-world code (e.g., Apache projects and Android apps). There exist several open-sourced and commercial security tools that automatically screen Java programs to detect misuses. To compare their accuracy and security guarantees, we develop two comprehensive benchmarks named CryptoAPI-Bench and ApacheCryptoAPI-Bench. CryptoAPI-Bench consists of 181 unit test cases that cover basic cases, as well as complex cases, including interprocedural, field sensitive, multiple class test cases, and path sensitive data flow of misuse cases. The benchmark also includes correct cases for testing false-positive rates. The ApacheCryptoAPI-Bench consists of 121 cryptographic cases from 10 Apache projects. We evaluate four tools, namely, SpotBugs, CryptoGuard, CrySL, and another tool (anonymous) using both benchmarks. We present their performance and comparative analysis. The ApacheCryptoAPI-Bench also examines the scalability of the tools. Our benchmarks are useful for advancing state-of-the-art solutions in the space of misuse detection.

Automatic Detection of Java Cryptographic API Misuses: Are We There Yet?

The Java platform provides various cryptographic APIs to facilitate secure coding. However, correctly using these APIs is challenging for developers who lack cybersecurity training. Prior work shows that many developers misused APIs and consequently introduced vulnerabilities into their software. To eliminate such vulnerabilities, people created tools to detect and/or fix cryptographic API misuses. However, it is still unknown (1) how current tools are designed to detect cryptographic API misuses, (2) how effectively the tools work to locate API misuses, and (3) how developers perceive the usefulness of tools’ outputs. For this paper, we conducted an empirical study to investigate the research questions mentioned above. Specifically, we first conducted a literature survey on existing tools and compared their approach design from different angles. Then we applied six of the tools to three popularly used benchmarks to measure tools’ effectiveness of API-misuse detection. Next, we applied the tools to 200 Apache projects and sent 57 vulnerability reports to developers for their feedback. Our study revealed interesting phenomena. For instance, none of the six tools was found universally better than the others; however, CogniCrypt, CogniGuard, and Xanitizer outperformed SonarQube. More developers rejected tools’ reports than those who accepted reports (30 versus 9) due to their concerns on tools’ capabilities, the correctness of suggested fixes, and the exploitability of reported issues. This study reveals a significant gap between the state-of-the-art tools and developers’ expectations; it sheds light on future research in vulnerability detection.

Cassandra is a Better Option for Handling Big Data in a No-SQL Database

With no single point of failure and the flexibility to handle enormous volumes of data across numerous commodity servers, Apache Cassandra is an opensource distributed database management system. With asynchronous master less replication, Cassandra provides strong support for clusters spanning several datacenters and enables low latency operations for all clients. Like skilled carpenters, data engineers are aware that certain tasks call for various tools. Choosing the appropriate equipment and being knowledgeable about their use can be the most crucial aspects of any job. A distributed information system for managing massive amounts of structured data across multiple goods servers, Apache Cassandra, a top-level Apache project developed at Facebook and based on Google's Big Table and Amazon's Generator, offers extremely offered service and has no single point of failure. In comparison to other NoSQL databases and relational databases, Cassandra offers features including continuous availability, linear scale performance, operational simplicity, and straightforward knowledge distribution over various knowledge centers and cloud availability zones. Cassandra's capacity to scale, perform, and supply continuous time period is due to its design. Cassandra uses an attractive, simple-to-setup, and simple-to-maintain lordless "ring" design rather than a traditional master-slave or a manual and labor-intensive shared system. With continuous availability, linear scale performance, operational simplicity, and simple data distribution over numerous data centers and cloud availability zones, Apache Cassandra is a massively scalable open-source non-relational database. Cassandra was initially created at Facebook; it was open sourced in 2008; and in 2010, it was elevated to the status of a top-level Apache project.

Exploring multi-programming-language commits and their impacts on software quality: An empirical study on Apache projects

Context:Modern software systems (e.g., Apache Spark) are usually written in multiple programming languages (PLs). There is little understanding on the phenomenon of multi-programming-language commits (MPLCs), which involve modified source files written in multiple PLs. Objective:This work aims to explore MPLCs and their impacts on development difficulty and software quality. Methods:We performed an empirical study on eighteen non-trivial Apache projects with 197,566 commits. Results: (1) the most commonly used PL combination consists of all the four PLs, i.e., C/C++, Java, JavaScript, and Python; (2) 9% of the commits from all the projects are MPLCs, and the proportion of MPLCs in 83% of the projects goes to a relatively stable level; (3) more than 90% of the MPLCs from all the projects involve source files in two PLs; (4) the change complexity of MPLCs is significantly higher than that of non-MPLCs; (5) issues fixed in MPLCs take significantly longer to be resolved than issues fixed in non-MPLCs in 89% of the projects; (6) MPLCs do not show significant effects on issue reopen; (7) source files undergoing MPLCs tend to be more bug-prone; and (8) MPLCs introduce more bugs than non-MPLCs. Conclusions:MPLCs are related to increased development difficulty and decreased software quality.

The Ghost Commit Problem When Identifying Fix-Inducing Changes: An Empirical Study of Apache Projects

The SZZ approach for identifying fix-inducing changes traces backwards from a commit that fixes a defect to those commits that are implicated in the fix. This approach is at the heart of studies of characteristics of fix-inducing changes, as well as the popular Just-in-Time (JIT) variant of defect prediction. However, some types of commits are invisible to the SZZ approach. We refer to these invisible commits as “Ghost Commits.” In this paper, we set out to define, quantify, characterize, and mitigate ghost commits that impact the SZZ algorithm during its mapping (i.e., linking defect-fixing commits to those commits that are implicated by the fix) and filtering phases (i.e., removing improbable fix-inducing commits from the set of implicated commits). We mine the version control repositories of 14 open source Apache projects for instances of mapping-phase and filtering-phase ghost commits. We find that (1) 5.66–11.72 percent of defect-fixing commits of defect-fixing commits only add lines, and thus, cannot be mapped back to implicated commits; (2) 1.05–4.60 percent of the studied commits only remove lines, and thus, cannot be implicated in future fixes; and (3) that no implicated commits survive the filtering process of 0.35–14.49 percent defect-fixing commits. Qualitative analysis of ghost commits reveals that 46.5 percent of 142 addition-only defect-fixing commits add checks (e.g., null-ness or emptiness checks), while 39.7 percent of 307 removal-only commits clean up (unused) code. Our results suggest that the next generation of SZZ improvements should be language-aware to connect ghost commits to implicated and defect-fixing commits. Based on our observations, we discuss promising directions for mitigation strategies to address each type of ghost commit. Moreover, we implement mitigation strategies for addition-only commits and evaluate those strategies with respect to a baseline approach. The results indicate that our strategies achieve a precision of 0.753, improving the precision of implicated commits by 39.5 percentage points.

BugPre: an intelligent software version-to-version bug prediction system using graph convolutional neural networks

Since defects in software may cause product fault and financial loss, it is essential to conduct software defect prediction (SDP) to identify the potentially defective modules, especially in the early stage of the software development lifecycle. Recently, cross-version defect prediction (CVDP) began to draw increasing research interests, employing the labeled defect data of the prior version within the same project to predict defects in the current version. As software development is a dynamic process, the data distribution (such as defects) during version change may get changed. Recent studies utilize machine learning (ML) techniques to detect software defects. However, due to the close dependencies between the updated and unchanged code, prior ML-based methods fail to model the long and deep dependencies, causing a high false positive. Furthermore, traditional defect detection is performed on the entire project, and the detection efficiency is relatively low, especially on large-scale software projects. To this end, we propose BugPre, a CVDP approach to address these two issues. BugPre is a novel framework that only conducts efficient defect prediction on changed modules in the current version. BugPre utilizes variable propagation tree-based associated analysis method to obtain the changed modules in the current version. Besides, BugPre constructs graph leveraging code context dependences and uses a graph convolutional neural network to learn representative characteristics of code, thereby improving defect prediction capability when version changes occur. Through extensive experiments on open-source Apache projects, the experimental results indicate that our BugPre outperforms three state-of-the-art defect detection approaches, and the F1-score has increased by higher than 16%.

Evolving software forges: An experience report from Apache Allura

AbstractThe open‐source phenomenon has reached unimaginable proportions to a point in which it is virtually impossible to find large applications that do not rely on open‐source as well. However, such proportions may turn into a risk if the organizational and socio‐technical aspects (e.g., the contribution and release schemes) behind open‐source communities are not explicitly supported by open‐source forges by‐design. In an effort to make such aspects explicit and supported by‐design in open‐source forges, we conducted empirical software engineering as follows: (a) Through online industrial surveying, we elicited organizational and social aspects relevant in open‐source communities; (b) through action research, we extended a widely known open‐source support system and top‐level Apache project Allura; (c) through ethnography, we studied the Allura community, and learning from its social and organizational structure, (d) we elicited a metrics framework that support more explicit organizational and socio‐technical design principles around open‐source communities. This article is an experience report on these results and the lessons we learned in obtaining them. We found that the extensions provided to Apache Allura formed the basis for community awareness by design, providing valuable and usable community characteristics. Ultimately, however, the extensions we provided to Apache Allura were deactivated by its core developers because of performance overheads. Our results and lessons learned allow us to provide recommendations for designing forges, like Github. Architecting a forge is a participatory process that requires active engagement, hence remarking the need for mechanisms enabling it. At the same time, we conclude that a more active support for the governance is required to avoid the failure of the forge.

The Impact of Dormant Defects on Defect Prediction: A Study of 19 Apache Projects

Defect prediction models can be beneficial to prioritize testing, analysis, or code review activities, and has been the subject of a substantial effort in academia, and some applications in industrial contexts. A necessary precondition when creating a defect prediction model is the availability of defect data from the history of projects. If this data is noisy, the resulting defect prediction model could result to be unreliable. One of the causes of noise for defect datasets is the presence of “dormant defects,” i.e., of defects discovered several releases after their introduction. This can cause a class to be labeled as defect-free while it is not, and is, therefore “snoring.” In this article, we investigate the impact of snoring on classifiers' accuracy and the effectiveness of a possible countermeasure, i.e., dropping too recent data from a training set. We analyze the accuracy of 15 machine learning defect prediction classifiers, on data from more than 4,000 defects and 600 releases of 19 open source projects from the Apache ecosystem. Our results show that on average across projects (i) the presence of dormant defects decreases the recall of defect prediction classifiers, and (ii) removing from the training set the classes that in the last release are labeled as not defective significantly improves the accuracy of the classifiers. In summary, this article provides insights on how to create defects datasets by mitigating the negative effect of dormant defects on defect prediction.

Predicting defects in object-oriented software using cost-sensitive classification

In this software era, it is vital to produce reliable and good quality software. Early detection of defects aids in building accurate software with reduced cost and other resources. Researchers have a keen interest in producing machine learning models for effective and accurate software defect prediction in the early stages of software development. Object-oriented metrics of the software are used in developing these models. These models may result in biased predictions owing to the class imbalance problem existing in most of the software datasets. This paper provides an effective defect prediction framework for imbalanced data by employing cost-sensitive classifiers and stable performance measures like GMean, Balance, and AUC. Four decision tree-based classifiers with different cost ratios are investigated to predict defects in three Apache projects. The empirical results are statistically validated using the nonparametric Friedman test and Wilcoxon signed-rank test. The results state with 99% confidence that the predictive capability of J48, AdaBoostM1, Bagging, and RandomSubSpace improved after employing cost-sensitive learning for the four classifiers used in this study.

Information Retrieval from Software Bug Ontology Exploiting Formal Concept Analysis

Knowledge extraction and structuring is attaining importance in real world applications such as e-commerce, decision support, problem solving and semantic web. Extraction of knowledge from collection of text documents is based upon identification of semantic content. Ontology plays an important role in accessing and structuring information. Developing an ontology are at the core of new strategies which requires accurate domain knowledge. Identification of structural and logical concepts is a time-consuming process. This work presents an ontology-based retrieval approach, that visualizes and structure the data of software bug reports domain. It exploits formal concept analysis (FCA) to elicit conceptualizations from bug reports datasets and a hierarchical taxonomy is generated of extracted knowledge. A lattice diagram of concepts and relationships is constructed from concept-relationship matrix created by FCA. Ontology is constructed on fluent editor tool and knowledge is extracted with the help of small queries executed on a reasoner window. The proposed approach is evaluated on 21 bug reports of apache projects of jira repository. It can be concluded that information can be retrieved easily from ontology as compared to manual extraction of data.

HealtheDataLab \u2013 a cloud computing solution for data science and advanced analytics in healthcare with application to predicting multi-center pediatric readmissions

BackgroundThere is a shortage of medical informatics and data science platforms using cloud computing on electronic medical record (EMR) data, and with computing capacity for analyzing big data. We implemented, described, and applied a cloud computing solution utilizing the fast health interoperability resources (FHIR) standardization and state-of-the-art parallel distributed computing platform for advanced analytics.MethodsWe utilized the architecture of the modern predictive analytics platform called Cerner® HealtheDataLab and described the suite of cloud computing services and Apache Projects that it relies on. We validated the platform by replicating and improving on a previous single pediatric institution study/model on readmission and developing a multi-center model of all-cause readmission for pediatric-age patients using the Cerner® Health Facts Deidentified Database (now updated and referred to as the Cerner Real World Data). We retrieved a subset of 1.4 million pediatric encounters consisting of 48 hospitals’ data on pediatric encounters in the database based on a priori inclusion criteria. We built and analyzed corresponding random forest and multilayer perceptron (MLP) neural network models using HealtheDataLab.ResultsUsing the HealtheDataLab platform, we developed a random forest model and multi-layer perceptron model with AUC of 0.8446 (0.8444, 0.8447) and 0.8451 (0.8449, 0.8453) respectively. We showed the distribution in model performance across hospitals and identified a set of novel variables under previous resource utilization and generic medications that may be used to improve existing readmission models.ConclusionOur results suggest that high performance, elastic cloud computing infrastructures such as the platform presented here can be used for the development of highly predictive models on EMR data in a secure and robust environment. This in turn can lead to new clinical insights/discoveries.

Inferring Bug Signatures to Detect Real Bugs

Static tools like Findbugs allow their users to manually define bug patterns, so they can detect more types of bugs, but due to the complexity and variety of programs, it is difficult to manually enumerate all bug patterns, especially for those related to API usages or project-specific rules. Therefore, existing bug-detection tools (e.g., Findbugs) based on manual bug patterns are insufficient in detecting many bugs. Meanwhile, with the rapid development of software, many past bug fixes accumulate in software version histories. These bug fixes contain valuable samples of illegal coding practices. The gap between existing bug samples and well-defined bug patterns motivates our research. In the literature, researchers have explored techniques on learning bug signatures from existing bugs, and a bug signature is defined as a set of program elements explaining the cause/effect of the bug. However, due to various limitations, existing approaches cannot analyze past bug fixes in large scale, and to the best of our knowledge, no previously unknown bugs were ever reported by their work. The major challenge to automatically analyze past bug fixes is that, bug-inducing inputs are typically not recorded, and many bug fixes are partial programs that have compilation errors. As a result, for most bugs in the version history, it is infeasible to reproduce them for dynamic analysis or to feed buggy/fixed code directly into static analysis tools which mostly depend on compilable complete programs. In this paper, we propose an approach, called <small>DePa</small>, that extracts bug signatures based on accurate partial-code analysis of bug fixes. With its support, we conduct the first large scale evaluation on 6,048 past bug fixes collected from four popular Apache projects. In particular, we use <small>DePa</small> to infer bug signatures from these fixes, and to check the latest versions of the four projects with the inferred bug signatures. Our results show that <small>DePa</small> detected 27 unique previously unknown bugs in total, including at least one bug from each project. These bugs are not detected by their developers nor other researchers. Among them, three of our reported bugs are already confirmed and repaired by their developers. Furthermore, our results show that the state-of-the-art tools detected only two of our found bugs, and our filtering techniques improve our precision from 25.5 to 51.5 percent.