How effective are existing Java API specifications for finding bugs during runtime verification?

• Published in: Automated software engineering Vol. 26; no. 4; pp. 795 - 837
• Main Authors: Legunsen, Owolabi, Al Awar, Nader, Xu, Xinyue, Hassan, Wajih Ul, Roşu, Grigore, Marinov, Darko
• Format: Journal Article
• Language: English
• Published: New York Springer US 01.12.2019; Springer Nature B.V
• Subjects: Application programming interface; Artificial Intelligence; Computer Science; Effectiveness; False alarms; Formal specifications; Software development; Software Engineering/Programming and Operating Systems; Verification; Violations; Software testing; Monitoring-oriented programming; Specification quality; Empirical study; Runtime verification
• ISSN: 0928-8910; 1573-7535
• DOI: 10.1007/s10515-019-00267-1

Runtime verification can be used to find bugs early, during software development, by monitoring test executions against formal specifications (specs). The quality of runtime verification depends on the quality of the specs. While previous research has produced many specs for the Java API, manually or through automatic mining, there has been no large-scale study of their bug-finding effectiveness . Our conference paper presented the first in-depth study of the bug-finding effectiveness of previously proposed specs. We used JavaMOP to monitor 182 manually written and 17 automatically mined specs against more than 18K manually written and 2.1M automatically generated test methods in 200 open-source projects. The average runtime overhead was under 4.3 × . We inspected 652 violations of manually written specs and (randomly sampled) 200 violations of automatically mined specs. We reported 95 bugs, out of which developers already fixed or accepted 76. However, most violations, 82.81% of 652 and 97.89% of 200, were false alarms. Based on our empirical results, we conclude that (1) runtime verification technology has matured enough to incur tolerable runtime overhead during testing, and (2) the existing API specifications can find many bugs that developers are willing to fix; however, (3) the false alarm rates are worrisome and suggest that substantial effort needs to be spent on engineering better specs and properly evaluating their effectiveness. We repeated our experiments on a different set of 18 projects and inspected all resulting 742 violations. The results are similar, and our conclusions are the same.