2020 IEEE 44th Annual Computers, Software, and Applications Conference (COMPSAC)

Does This Code Change Aﬀect Program Behavior?
–Identifying Nonbehavioral Changes with Bytecode–Aoi Maejima∗ , Yoshiki Higo∗ , Junnosuke Matsumoto† and Shinji Kusumoto∗∗ Graduate School of Information Science and Technology, Osaka University, Japan{a-maejim, higo, j-matumt, kusumoto}@ist.osaka-u.ac.jp

Abstract—Developers occasionally conduct somesource code changes that do not aﬀect program behavior. We call such changes nonbehavioral changes. In
this research, we propose a technique for determining
whether a given commit includes only nonbehavioral
changes or not by checking the diﬀerences of bytecodeon the commit. If the bytecode is not aﬀected by
the commit, the proposed technique determines thatthe commit includes only nonbehavioral changes. As aresult of experiments on six Java open source projects,
out of the commits in which Java source ﬁles werechanged, the commits of 8.6%∼22.4% consisted of only
nonbehavioral changes. We also found new 25 patternsof nonbehavioral changes compared to a previous study.
Index Terms—MSR, change analysis, bytecodeI. Introduction
There are many techniques to mine changes in code
repositories. Mined changes have been used in various
research studies such as defect prediction [1], [2] and code
dependency detection [3], [4]. Some code changes such as
modifying existing functions aﬀect the program behavior.
In contrast, other changes such as changing variable names
do not aﬀect the program behavior. In this research, we
use term behavioral changes and nonbehavioral changes toshow the former and the latter changes, respectively. Nonbehavioral changes are conducted to improve readability,
maintainability, or other attributes of the source code.
In this paper, we propose a technique to classify codechanges into behavioral/nonbehavioral ones by using bytecode. The key idea of our technique is that, if the bytecode
after a given change is the same as the bytecode before thechange, the change is regarded as a nonbehavioral one.
Thus, our classiﬁcation does not involve any subjectivity.
We conducted a small experiment on six open source
projects to answer the following research questions.
RQ1 How do many nonbehavioral changes exist?
RQ2 What nonbehavioral changes were conducted?
TABLE I: Target projects and targer periods
ProjectkGenProg
Apache Ant
Spring Framework Core
Hibernate ORM Core
Apache Tomcat
Apache POIStart date
09/Apr/2018
01/Jan/2017
15/Aug/2016
16/Dec/2016
04/Jul/2017
26/Jan/2018978-1-7281-7303-0/20/$31.00 ©2020 IEEE
DOI 10.1109/COMPSAC48688.2020.0-119

II. Identifying Nonbehavioral Changes
In this research, we identify nonbehavioral changes according to the presence or absence of bytecode changes forgiven source code changes. We deﬁne that code changes
that aﬀect the byte are behavioral, and the others arenonbehavioral. Our technique creates another repositorythat is composed of Java source ﬁles and their decompiledbytecode. In the created repository, commits in which onlyJava source ﬁles are changed are nonbehavioral commits.
A. rjava Filesrjava ﬁles means ﬁles including decompiled bytecode.
We use command ‘javap -p -c [file]’ to decompile a
bytecode ﬁle included in class ﬁles. Option ‘-p’ speciﬁes
that all methods and ﬁelds, including private ones, aredecompiled. Option ‘-c’ speciﬁes that all instructions inmethods are decompiled, not only method signatures.
B. Creating a Census Repository
The following steps are iterated for all the commits
included in a given repository to create a census repository
including java and rjava ﬁles.
1) retrieve java ﬁles in a given commit.
2) compile java ﬁles to make class ﬁles.
3) decompile class ﬁles to make rjava ﬁles.
4) commit java/rjava ﬁles to the census repository.
C. Identifying Nonbehavioral Changes
We examine the change history of the census repository.
If at least a rjava ﬁle is changed together with java ﬁles,the commit is regarded as a behavioral commit. Otherwise,
the commit is regarded as a nonbehavioral one.
III. Experiment
We conducted an experiment on six Java projects. Table I shows the target projects and the target periods. The
testing ﬁles in the projects are ignored in the experiment.
TABLE II: Number of commits in which java ﬁles withor without rjava ﬁles were changed

End date
04/Nov/2019
22/May/2019
24/Jan/2020
31/Jan/2020
15/Jan/2020
13/Jan/2020

ProjectkGenProg
AntSpring
Hibernate
Tomcat
POI1103# .java commits
808
323
851
1,253
1,800
255

# commits w/o .rjava
157 (19.4%)
64 (19.8%)
191 (22.4%)
114 ( 9.1%)
278 (15.4%)
22 ( 8.6%)

A. Analysis for RQ1

IV. Conclusion

The experimental results are shown in Table II. Our
answer to RQ1 is that among the commits in which atleast a java ﬁle was changed, the commits of 8.6%∼22.4%
consist only of nonbehavioral changes.
B. Analysis for RQ2
We conducted visual conﬁrmation for all the nonbehavioral commits for the projects. Table IV shows a list of
the patterns of the nonbehavioral changes that we found.
Table III shows the ratio of changes in the newly-detected
patterns against all the nonbehavioral changes. The ratio
is between 20.0%∼39.6%. Our answer to RQ2 is that
we found 31 patterns of nonbehavioral changes, whereas
the previous research [5] deﬁned the six patterns. The
upper six patterns in Table IV can be detected by theprevious research too, while the remaining 25 patterns canbe detected only by our technique.
TABLE III: Newly-detected nonbehavioral changes
ProjectkGenProg
Ant
SpringHibernateTomcatPOI# all nonbehavioral
changes
164
75
245
139
324
35

# newly-detected
nonbehavioral changes
65 (39.6%)
15 (20.0%)67 (27.3%)
37 (26.6%)
69 (21.3%)
8 (22.9%)In this paper, we proposed a technique to identify nonbehavioral changes according to the presence or absenceof bytecode changes. As a result of the investigation,
we conﬁrmed that in the six Java projects, the commitsof 8.6%∼22.4% consisted of only nonbehavioral changes.
Moreover, 25 new changes were deﬁned as nonbehavioral
changes compared to the previous research [5].
In the next step, we are going to apply our techniqueto reduce testing time in software developments with
continuous integration.
References[1] T. L. Graves, A. F. Karr, J. S. Marron, and H. Siy, “Predicting
fault incidence using software change history,” IEEE Transactions on Software Engineering, vol. 26, no. 7, pp. 653–661, July
2000.
[2] N. Nagappan and T. Ball, “Use of relative code churn measures topredict system defect density,” in Proc. International Conference
on Software Engineering, May. 2005, pp. 284–292.
[3] H. Gall, M. Jazayeri, and J. Krajewski, “Cvs release history datafor detecting logical couplings,” in Proc. International Workshop
on Principles of Software Evolution, Sep. 2003, pp. 13–23.
[4] A. T. T. Ying, G. C. Murphy, R. Ng, and M. C. Chu-Carroll,“Predicting source code changes by mining change history,” IEEE
Transactions on Software Engineering, vol. 30, no. 9, pp. 574–586, Sep. 2004.
[5] D. Kawrykow and M. P. Robillard, “Non-essential changes inversion histories,” in Proc. International Conference on Software
Engineering, May. 2011, pp. 351–360.

TABLE IV: Patterns of Nonbehavioral Changes
PatternCommits
Formats
Trivial Type Update
Local Variable Renames
Method Parameter Renames
this. Insertions/Deletions
final Insertions/Deletions
Import Statements
Annotations
public Insertions/Deletionsfor Methods in Interfaces
Unnecessary Casts
Type in Lambda Expressions
Empty Statements
De Morgan in Expressions
Parentheses Expressions
Brackets for Blocks
If-Condition Consolidation
if-else-if to two if
Unnecesary else
Generics
Diamond Operator
Array Type Deﬁnition
Reorder Modiﬁers
Empty String Concatination
Init. w/ or w/o Static Block
Iterator to Enhanced For-Block
Autoboxing and Unboxing
Number Type Speciﬁcation
Use Constants
static for Enum Declarations
Semicolon for Enum Constants

Total
457 (46.7%)
212 (21.7%)
11 ( 1.1%)
22 ( 2.2%)
12 ( 1.2%)
7 ( 0.7%)
22 ( 2.2%)
56 ( 5.7%)
100 (10.2%)

kGenProg
56 (34.1%)
26 (15.9%)
2 ( 1.2%)
10 ( 6.1%)
3 ( 1.8%)2 ( 1.2%)
19 (11.6%)
18 (11.0%)
25 (15.2%)

3 ( 0.3%)

1 ( 0.6%)

1 ( 0.1%)
1 ( 0.1%)
5 ( 0.5%)
1 ( 0.1%)
11 ( 1.1%)
11 ( 1.1%)
1 ( 0.1%)
1 ( 0.1%)
1 ( 0.1%)
8 ( 0.8%)
4 ( 0.4%)
1 ( 0.1%)
2 ( 0.2%)
1 ( 0.1%)
1 ( 0.1%)
1 ( 0.1%)
19 ( 1.9%)
1 ( 0.1%)
1 ( 0.1%)
3 ( 0.3%)
1 ( 0.1%)

1 ( 0.6%)Ant
42 (56.0%)
15 (20.0%)
1 ( 1.3%)
1 ( 1.3%)
1 ( 1.3%)
5 ( 6.7%)
5 ( 6.7%)

Spring133 (55.1%)
30 (12.4%)
4 ( 1.7%)
5 ( 2.1%)
2 ( 0.8%)
4 ( 1.7%)
1 ( 0.4%)
14 ( 5.8%)
31 (12.9%)

Hibernate
61 (43.9%)40 (28.8%)1( 0.7%)

Tomcat150 (46.3%)
93 (28.7%)
3 ( 0.9%)5 ( 1.5%)
4 ( 1.2%)

POI
15 (42.9%)
8 (22.9%)1 ( 2.9%)1 ( 2.9%)1 ( 2.9%)1 ( 2.9%)

1 ( 0.7%)
9 ( 6.5%)
22 (15.8%)

1 ( 0.3%)
8 ( 2.5%)
16 ( 4.9%)

2 ( 5.7%)
1 ( 2.9%)

1 ( 0.7%)

1 ( 0.3%)

1 ( 2.9%)2 ( 1.4%)

3 ( 0.9%)8 ( 2.5%)

1 ( 2.9%)1 ( 2.9%)2 ( 1.4%)
1 ( 0.4%)
1 ( 0.4%)
1 ( 0.4%)
7 ( 2.9%)

1 ( 0.6%)

1 ( 1.3%)
3 ( 4.0%)
1 ( 1.3%)

1 ( 0.4%)
1 ( 0.4%)
3 ( 1.2%)
1 ( 0.4%)
1 ( 0.4%)

2 ( 0.6%)
3 ( 0.9%)
1 ( 0.3%)
1 ( 0.3%)
1 ( 0.3%)
1 ( 0.3%)
19 ( 5.9%)
1 ( 2.9%)
1 ( 0.3%)
3 ( 0.9%)1 ( 2.9%)1104