Modern software systems, such as Spark, are usually written in multiple programming languages (PLs). Besides benefiting from code reuse, such systems can also take advantages of specific PLs to implement certain features, to meet various quality needs, and to improve development efficiency. In this context, a change to such systems may need to modify source files written in different PLs. We define a multi-programming-language commit (MPLC) in a version control system (e.g., Git) as a commit that involves modified source files written in two or more PLs. To our knowledge, the phenomenon of MPLCs in software development has not been explored yet. In light of the potential impact of MPLCs on development difficulty and software quality, we performed an empirical study to understand the state of MPLCs, their change complexity, as well as their impact on open time of issues and bug proneness of source files in real-life software projects. By exploring the MPLCs in 20 non-trivial Apache projects with 205,994 commits, we obtained the following findings: (1) 9% of the commits from all the projects are MPLCs, and the proportion of MPLCs in 80% of the projects goes to a relatively stable level; (2) more than 90% of the MPLCs from all the projects involve source files written in two PLs; (3) the change complexity of MPLCs is significantly higher than that of non-MPLCs in all projects; (4) issues fixed in MPLCs take significantly longer to be resolved than issues fixed in non-MPLCs in 80% of the projects; and (5) source files that have been modified in MPLCs tend to be more bug-prone than source files that have never been modified in MPLCs. These findings provide practitioners with useful insights on the architecture design and quality management of software systems written in multiple PLs.

Defect technical debt (defect debt) refers to known deferred bugs that have not been fixed. The interest of a defect debt item (i.e., bug) is the extra effort needed to fix the bug due to the delay of fixing. It is important to measure defect debt interest in a software system in order to be aware of how much the interest of certain bugs is and which bugs should be fixed first. Furthermore, it is valuable to understand the features of the bugs of high interest or no interest, so as to facilitate the identification of those kinds of bugs. In this work, we proposed three pairs of measures for quantifying defect debt interest at three granularities (i.e., lines of code, source file, and package) of software changes, and conducted an exploratory case study on 13,438 bugs collected from 59 non-trivial Apache open source software projects written mainly in Java. We have the following findings. (1) Each bug, with an average of 224 days delay of fixing, has interest of 660 to 845 lines of code, 0.57 to 1.05 source files, and 0.29 to 0.35 package on average in need for understanding or modifying when fixing the bug. (2) The average interest of a bug shows overall increasing trends over delayed time of bug fixing and bug priority levels from the lowest to highest. (3) Around 30% of the bugs under study did not incur interest at the granularity of lines of code, which means that the involved source files in the bug-fixing commits of such bugs were not modified at all during the delayed time of bug fixing. (4) The average code change size of bug-fixing commits of a bug without interest is much smaller than that of a bug with (high) interest; for a bug without interest at the granularity of lines of code, the source files involved in the bug-fixing commits of the bug were alternately modified by different committers much less frequently than those of the bug with (high) interest.