Evolution Analysis forAccessibility Excessiveness in Java
Kazuo Kobori

Makoto Matsushita

Katsuro Inoue

NTT DATA Corporation
3-3-3, Toyosu, Koto
Tokyo 135-6033, Japan

Osaka University
1-5 Yamadaoka, Suita
Osaka 565-0871, Japan

Osaka University
1-5 Yamadaoka, Suita
Osaka 565-0871, Japan

Abstract—In Java programs, access modiﬁers are used tocontrol the accessibility of ﬁelds and methods from other objects.
Choosing appropriate access modiﬁers is one of the key factors to
improve program quality and to reduce potential vulnerability. In
our previous work, we presented a static analysis method named
Accessibility Excessiveness (AE) detection for each ﬁeld andmethod in Java program. We have also developed an AE analysis
tool named ModiChecker that analyzes each ﬁeld and method of
the input Java programs, and reports their excessiveness. In thispaper, we have applied ModiChecker to several OSS repositories
to investigate the evolution of AE over versions, and identiﬁed
transition of AE status and the difference in the amount of AE
change between major version releases and minor ones. Also we
propose when to evaluate source code with AE analysis.

I. I NTRODUCTION
Access modiﬁers in Java [27] are access level directions
for classes, constructors, methods, and ﬁelds. There are fouraccess levels in Java:• public is visible to all classes everywhere.
• default is visible only within its own package.
• private can only be accessed in its own class.
• protected can only be accessed within its own package and, in addition, by a subclass of its class in anotherpackage.
Proper use of access modiﬁers and controlling visibility are
essential to well-encapsulated Java programming [2], [3].
To realize good encapsulation in Java programming, wehave to carefully choose appropriate access modiﬁers for ﬁelds
and methods in a class, which are accessed by many otherobjects. However, inexperienced developers might simply set
all of the access modiﬁers public indiscriminately.
For example, Fig. 1 is a case of bad access modiﬁer setting.
Suppose that we have 2 methods: Method A and Method
B in class X. Method A has an initialization process for
Method B. It means that Method A must be called before
Method B is called. Otherwise, Method B can not work
properly. In this case, Method B should be always called
via Method A, and then the access modiﬁer of Method B
should be private. However, a novice developer might set
such access modiﬁer public without thinking seriously. Ina meanwhile, other developer would want to use Method B
and he/she would directly call it since the access modiﬁer of
Method B allows direct access to it. This may cause a fault
due to lack of the initialization process performed by Method
A.

Class X...
public method A
Initialization process

Bad callfrom outside X

Call from A
public method B
Main process...
Fig. 1. Inappropriate Access Modiﬁer Declaration

In this example, the access modiﬁer of Method B is declared as public, but the current program calls Method B
only from a private method (Method A in this case), andthen the access modiﬁer of Method B should be private.
A discrepancy between the declared accessibility and actual
usage of a ﬁeld or method is called Accessibility Excessiveness(AE) here, and AE can be a cause of program faults due tounintended use of the ﬁelds or methods.
Existence of AE would be a bad smell of program, and it
would indicate various issues on the designs and developments
of program as follows.
1) Immature Design and Programming Issues: An AE
would cause unwilling access to a ﬁeld or method
which should not be accessed by other objects in alater development or maintenance phases as shown in
the example. This is an issue of design and development
processes from the view point of encapsulation [3]. This
problem shows the immaturity and carelessness of thedesigner and developer.
2) Maintenance Issues: Sometimes the developer intentionally set ﬁeld or method excessive for future use or forthe purpose of being called from other programs. It isnot easy to distinguish whether AE is intentionally set
by the developer or it is a case of Issue 1, so that themaintenance of such program is complicated and is notstraightforward.
3) Security Vulnerability Issues: A program with AE has
potential vulnerability of its security in the sense that an
attacker may access an AE ﬁeld and/or method against
the intention of the program designer and developer [21].
In this paper, we will discuss on an AE analysis method
mostly focusing on its application to Issue 1), and also mention
Issue 2) in our tool implementation. Issue 3) will be a further
research topic. If the maintenance issue would be resolved, we
could identify unintentionally set ﬁelds and methods easily,
and ﬁx them with appropriate accessibility modiﬁers. Thatmight improve the quality of the software.
We have developed an AE analysis tool ModiChecker [12],which takes a Java program as input, then analyzes and reports
the excessiveness of each access modiﬁer declared at ﬁelds andmethods. Also it can change the detected access modiﬁers toproper ones under the consultation of the developer.
ModiChecker is based on a static program analysis framework MASU [8], [16], [31], which allows a ﬂexible composition of various analysis tools very easily.
Using ModiChecker, we have analyzed several open source
software (OSS) systems to investigate the transition of AE
state from a version to a next version, and the evolution of
AE analysis results over multiple versions of these systems.
As a result, we obtained some observation for the relation ofevolution and AE.
The contributions of this paper are as follows.
(i) We propose an AE classiﬁcation model for the ﬁelds
and methods of Java program. Based on this model, we
also deﬁne AE metrics, which would be an indicator ofbad smell of the target program.
(ii) Empirical results of AE analyses for various OSS systems have been presented, including transition patterns
and evolution pattern of AE metrics.
In the following, we will show AE classiﬁcation model in
Section 2. Section 3 will describe an AE analysis method andModiChecker with Java analysis framework MASU. In Section
4, we will show our experiments of using ModiChecker withseveral research questions. Section 5 will discuss our approachand results associated with related works. Section 6 willconclude our discussions with a few future works.
II. ACCESSIBILITY E XCESSIVENESS C LASSIFICATIONM ODEL
Table I shows Accessibility Excessiveness Classiﬁcation(AE classiﬁcation), which lists all the combinations of thedeclarations and actual usages. The vertical column shows
the declaration of an access modiﬁer for a ﬁeld or methodin the source code. The horizontal row shows its actual usage
from other objects. Each element in AE classiﬁcation is an
Accessibility Excessive identiﬁer (AE id) which identiﬁes each
AE case. For example, if a method has public as thedeclaration of the access modiﬁer, and it is accessed only by

TABLE IACCESSIBILITY E XCESSIVENESS C LASSIFICATION

hhhh
Usage
hhActualhhhh
DeclarationhPublicProtected
Default
PrivatePublicProtected

Default

PrivateNo Accesspub-pub–––

pub-propro-pro––pub-def
pro-def
def-def–

pub-pri
pro-pri
def-pripri-pri

pub-napro-nadef-napri-nathe objects of the same class, the AE id is pub-pri meaningthat it could be set to private.
We also deﬁne AE ids for special cases. AE ids pubpub, pro-pro, def-def, and pri-pri are the cases that there isno discrepancy between the declaration and actual usage, so
those are proper cases for quality programming. AE ids pubna, pro-na, def-na, and pri-na indicate that those ﬁelds or
methods are declared but they are never used. These two cases
are technically not AE in the sense those are not ordinary
discrepancy between the declaration and actual usage, but
we include them for better understanding of access modiﬁers
usage. In total, we will use 14 AE ids here. The cases with“–” means that those are detected as error at the compilation
time, so that those are not executable program and they areout of the scope of the AE analysis.
The purpose of the AE analysis is to determine an AE id
for each ﬁeld and method in the input program.
Also, we are interested in the statistic measures of AE
ids for the input program, which would be important cluesof program quality. Here, we deﬁne AE ﬁeld metric and AE
method metric for a program. The AE ﬁeld metric is a setof the metric values for all 14 AE ids: {|pub − pub|, |pub −pro|, ..., |def − na|, |pri − pri|, |pri − na|}, where |AEid|means the number of the ﬁelds having that AE id in the
input program. In the same way the AE method metric isalso deﬁned. We may simply call AE metric to mean either
AE ﬁeld metric or AE method metric.
III. AE A NALYSIS T OOL M ODI C HECKER
A. Approach to AE Analysis
To perform the AE analysis, we need to know the declaration of the access modiﬁers of each ﬁeld or method of the
input program. This is easily done by parsing the program.
Also, we have to investigate into the actual usage of eachﬁeld or method. For this work, we employ a static sourcecode analysis, which identiﬁes other classes that may possiblyaccess the target ﬁeld or method. For these purposes, we haveused a Java program analysis framework MASU [8], [16], [31].
MASU has been originally designed to implement pluggable
multi-linguistic metric infrastructure, but it is very useful as aJava program analysis framework. MASU transforms the inputJava program into a language-independent Abstract Syntax
Tree (AST). For this AST, various analyses are performedon class level, method level, and variable level. Caller-callee
relations and variable usage are obtained by these analyses.

Inputclass A

AST
construction
Masu
framework

Source code

Used publicly

AST
analysispublic method C( )AST DB

Required library( .jar files)

Access modifier
declaration
analysis

AE report

Developerclass B
Field/method
usage analysis

Discrepancy
detection

Used privately
public method C( )Fig. 3. Access Modiﬁer of Overriding Method

Change instruction
Final output
Corrected source code

Source code
generation

ModiChecker

Fig. 2. Architecture of ModiChecker

B. Overview of ModiChecker Architecture
Fig. 2 shows the architecture of ModiChecker. Firstly,
ModiChecker reads source code and all of the required libraryﬁles (normally, the library ﬁles are in .jar ﬁles) in Java. The
source code is transformed to an AST associated with various
static code analysis results.
After analyzing the AST, we get the access modiﬁer declaration and also usage of each ﬁeld and method in AST database.
From the AST database, we can easily obtain the declarationof the access modiﬁer for each ﬁeld or method. Also, actual
usage of each ﬁeld and method, i.e., information of who may
access each ﬁeld or method, is also obtained from the AST
database.
By comparing the declaration and actual usage of the ﬁeld
and method, ModiChecker reports AE information to thedeveloper.
ModiChecker is a system with 521 source ﬁles and 102,250
LOC in Java, developed based on MASU framework as mentioned above. MASU framework itself accounts for 519 source
ﬁles and 102,000 LOC in Java (41,000 LOC are automaticallygenerated code by ANTLR [24]) .
C. Handling Special Cases
ModiChecker treats some special cases as follows.
Abstract Class and Interface: First, in the case of theabstract method declared in abstract class and interface, they
are not called from any instances. ModiChecker detects such
an abstract method and an interface, and reports No Access forthem. Second, in the case of the non-abstract method deﬁned
in an abstract class, ModiChecker reports AE in the same way
as a method deﬁned in a non-abstract class.
Overriding Methods: In the case of the method overriding
another method, that overriding method in a subclass musthave an access modiﬁer with an equal or more permissive levelto the access modiﬁer of the overridden method. ModiChecker
detects such an overriding method and reports AE between theaccess modiﬁer of the overridden method and its actual usage.
For example, in Fig. 3, assume that we have two classes
class A and class B with method A.C and method
B.C of access modiﬁer public for both. method B.C
overrides method A.C so ModiChecker does not recommend private for method B.C even if method B.C isactually used inside class B only.
In dynamic binding cases, if a class accesses a method of asuperclass, ModiChecker will consider that class also accesses
the method of all subclasses of the superclass. By this way,
dynamic binding cases should not bring about any bad effectto ModiChecker analysis result.
IV. E XPERIMENTS
In our previous work [12], we have applied ModiChecker toa single version of source code, and found some attributes of
AE including what kind of AEs are found, how many AEs arein the code itself. In this paper we would like to step forward
to analyze the evolution of source code, see when is the best
timing for developers to check AEs.
A. Research Questions and Targets
We have conducted several experiments with some open
source software (OSS) systems. The objectives of these experiments are to know the following research questions.
RQ1: Are the AE ﬁelds and methods are ﬁxed in thenext versions? What is the AE state transition in
the versions?
RQ2: Do the AE metric values change over OSS evolution? If so, what is the evolutional pattern?
We have performed these experiments on a PC workstation
with dual Intel Xeon 5160(3.00 GHz) processors and 8 GB
memory under Windows 7 Enterprise.
B. RQ1: Transition of AE StateWe are interested in knowing if AE state of a ﬁeld or method
is corrected immediately in the next version or not. Life cycleof AE is an intriguing research topic.

TABLE IIS UBJECT S OURCE F ORGE P ROJECTSNameApache Ant
Areca Backup
ArgoUMLFreeMind
JDT CorejEdit
Apache Struts

Versions
Investigated
1.1 – 1.8.4
5.0 – 7.2.17
0.10.1 – 0.34
0.0.2 – 0.9.0
2.0.1 – 3.7
3.0 – 4.5.2
1.0.2 – 2.3.7

Total
Versions
23
66
19
16
16
21
34

Number ofTransitions(Fields)
80920
13117085038
8676
13437450626
104218

Number ofTransitions(Methods)
18515625874825213030048
240726
99008
274271

Years
2003 – 20122007 – 20122002 – 20112000 – 2011
2002 – 20122000 – 20122002 – 2012

TABLE IIIS TATE T RANSITION R ATIO : F IELDS (%)

a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
q
r

Proper → Proper
AE → Proper
No Access → Proper
Proper → AE
AE → AENo Access → AE
Proper → No Access
AE → No Access
No Access → No Access
No Existence → Proper
No Existence → AE
No Existence → No Access
Proper → No existence
AE → No existence
No Access → No Existence
Not changed (Proper)
Not changed (AE)Not changed (No Access)

Ant
0.02
0.16
0.02
0.04
0.07
0.00
0.03
0.03
0.00
6.41
1.41
0.21
2.03
0.46
0.13
71.42
15.28
2.28

Areca
0.01
0.01
0.01
0.04
0.01
0.01
0.02
0.01
0.01
1.45
0.55
0.07
0.66
0.27
0.03
65.50
26.74
4.62

ArgoUML
0.03
0.42
0.05
0.04
0.04
0.02
0.19
0.07
0.05
6.84
1.56
1.38
4.05
2.20
1.36
58.72
12.26
10.72

FreeMind
0.12
0.31
0.07
0.38
0.17
0.01
0.21
0.02
0.00
22.59
7.13
3.27
7.28
2.80
2.04
35.85
12.99
4.75

JDT Core
0.02
0.30
0.07
0.22
0.12
0.01
0.06
0.05
0.00
4.08
1.79
0.24
0.80
0.78
0.09
64.98
22.72
3.66

jEdit
0.02
0.15
0.05
0.09
0.02
0.02
0.07
0.03
0.00
6.16
1.78
0.81
3.48
1.07
0.58
63.67
16.22
5.79

Struts
0.01
0.28
0.01
0.14
0.07
0.01
0.05
0.03
0.00
5.57
2.52
0.59
2.67
1.14
0.22
50.34
29.00
7.34

JDT Core
0.02
0.22
0.24
0.13
0.12
0.03
0.13
0.05
0.01
2.48
0.78
2.71
1.04
0.46
1.27
38.83
11.22
40.27

jEdit
0.02
0.16
0.13
0.15
0.03
0.03
0.19
0.05
0.00
3.85
1.38
3.32
2.12
0.86
1.85
38.58
14.02
33.24

Struts
0.00
0.07
0.09
0.04
0.03
0.13
0.05
0.01
0.00
1.96
1.52
5.73
0.73
1.08
2.99
19.16
11.07
55.34

TABLE IVS TATE T RANSITION R ATIO : M ETHODS (%)

a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
q
r

Proper → Proper
AE → Proper
No Access → Proper
Proper → AE
AE → AENo Access → AE
Proper → No Access
AE → No Access
No Access → No Access
No Existence → Proper
No Existence → AE
No Existence → No Access
Proper → No Existence
AE → No Existence
No Access → No Existence
Not changed (Proper)
Not changed (AE)Not changed (No Access)

Ant
0.03
0.10
0.13
0.05
0.06
0.08
0.07
0.05
0.01
2.31
1.08
4.44
0.54
0.28
0.95
26.46
12.89
50.47

Areca
0.00
0.03
0.07
0.02
0.00
0.01
0.05
0.00
0.00
1.10
0.28
1.10
0.63
0.19
0.71
44.30
11.88
39.64

We have investigated the repositories of seven OSS projects
written in Java obtained from SourceForge as shown in Table
II. Those were selected due to their long development histories
with sufﬁcient versions.
Transition of a ﬁeld and method with respect to the AE
state changes between two consecutive versions is presented

ArgoUML
0.03
0.12
0.26
0.08
0.05
0.03
0.25
0.06
0.02
3.63
1.06
5.48
1.88
0.84
3.44
28.44
8.92
45.42

FreeMind
0.12
0.26
0.36
0.13
0.09
0.04
0.34
0.03
0.02
12.34
2.10
17.41
5.41
0.68
9.72
23.29
3.10
24.55

in Figure 4. In this transition there are four states. Propermeans that the accessibility of the target ﬁeld or method isproper. AE indicates that the target is an AE ﬁeld or method,and No Access shows the target is not accessed by anyone. No
Existence means that the target does not exist at the previous
or next version. This state is employed to show the transitionsĂ͕Ɖ

Total AE Fields (without No Access)Total LOC (without comments)

Ğ͕Ƌ

Ő ŵ
Ŭ

ď Ŷ



Ĩ

Đ

Ś

1,800
120,000
1,600
100,000ůŽEŽĐĐĞƐƐ

ŝ͕ƌ

1,400
1,200

80,0001,000
60,000800
600

40,000Total AE Fields/Methods

Ě

2,000

140,000EŽǆŝƐƚĞŶĐĞ

Total LOC

WƌŽƉĞƌ

ũTotal AE Methods (without No Access)400
20,000
200
0
1.8.4

1.8.3

1.8.2

1.8.1

1.8.0

1.7.1

1.7.0

1.6.5

1.6.4

1.6.3

1.6.2

1.6.1

1.6.0

1.5.4

1.5.3.1

1.5

1.5.2

1.5.1

1.4

1.4.1

1.3

1.2

0
1.1

Fig. 4. Transition Diagram of Access Modiﬁers between Two Versions

Versionwhen a ﬁeld or method is newly added or deleted in the next
version.
All possible transitions are labeled from a–r. a and p areboth self transitions, but they are different in the sense that at
a some change for the access modiﬁer was made, and at p nochange was performed. In the same manner, e and i are thecases of some changes, and q and r are those of no change.
Table III and Table IV show the state transition ratios of theﬁelds and methods in each OSS system.
As we can see in these tables, one of the high ratio transitiongroup is self transitions without access modiﬁer change (i.e.,p, q, and r). This would mean that the access modiﬁers are
rarely revised in the next version.
Another high ratio is the transition from “No Existence toProper (j)” and “No Existence to No access (l).” For the ﬁeld
AE transition (Table III), we can see that j is generally higher
than l. This would mean that most of newly added ﬁelds haveproper access modiﬁers rather than just created. On the other
hand, for the method AE transition (Table IV), l is generally
higher than j, meaning that many methods are created without
preparing their use.
We can observe that the transition from “AE to No Existence(n)” shares higher ration than the transitions from “AE to
Proper (b)” in both cases of ﬁeld and method. This would
suggest that the developers tend to remove or completelychange the ﬁelds and methods, rather than to correct AE accessmodiﬁers.
Answer to RQ1: Changing the access modiﬁers for theﬁelds and methods are generally infrequent. They are
fairly stable even in the case of AE.
C. RQ2: Evolution of AE Metric Values
In previous section, we have observed that the AE state are
fairly stable once they are created in a version of source code.
Here, we have quantitatively analyzed the creation of AE ﬁelds
and methods over the evolution history.
We have examined 22 versions of Ant [23] from version
1.1 to 1.8.4, including 7 major version releases and 15 minor
version releases. We can identify a major version releaseby the second version number change for a version number

Fig. 5. Grow of AE Fields and Methods over Total LOC

composition “1.major.minor”. Other changes are minor version
releases.
Fig. 5 shows the growth of the total number of LOC ofeach version without counting comment lines, associated with
AE ﬁeld and method metric values of each version. A red
bar represents the total number of AE ﬁelds, and a green bar
indicates the total number of AE methods, both of which do
not include No Access or Proper AE ids.
We see there is a strong correlation between the total LOC
and AE ﬁelds/methods. The correlation coefﬁcients are 0.93
for LOC and AE ﬁelds and 0.98 for LOC and AE methods.
These indicate strong correlation between them. Also, as wehave discussed in previous subsection, AE methods exist morethan AE ﬁelds in all versions.
We have investigated the changes of AE metric values of
two consecutive versions. Fig. 6 shows the changes of thenumber of same AE ids in two consecutive versions of Ant.
Here, a change means that the the absolute value of thedifference of the number of AE ﬁelds in two versions. In mostcases, the newer version adds new AE ﬁelds, so the numberof the newer version is larger than that of the older version.
There are cases of small decreases in the newer versions, but
those are rare ones.
As we can see in this ﬁgure, when a major version release
happens, many changes on AE ﬁelds occur, most of which
are addition of new AE ﬁelds. In this case, many actual AE
ids such as pro-pri are added in the newer major versions. It
seems that there is signiﬁcant distinction of AE id changes
between major and minor version release cases.
Each AE id change has been examined by Mann-Whitney
U test to assess the signiﬁcance of the difference between
major and minor version release cases. With 5% signiﬁcancelevel, the difference was conﬁrmed for each AE id (pub-pro,
pub-def, pub-pri, pro-def, pro-pri, and def-pri) and each No
Access.

1400

250

1200

200

Major
versionreleaseMajor
versionrelease1000

pri-napri-nadef-na150

pro-nadef-na800

pro-napub-napub-nadef-pri
pro-pri100

def-pri
pro-pri600

pro-def

pro-def

pub-pri
pub-def
pub-propub-pri
pub-def

400

pub-pro

50
200

0
1.1
to
1.2

1.2
to
1.3

1.3
to
1.4

1.4 1.4.1 1.5 1.5.1 1.5.2 1.5.3.1 1.5.4 1.6.0 1.6.1 1.6.2 1.6.3 1.6.4 1.6.5 1.7.0 1.7.1 1.8.0 1.8.1 1.8.2 1.8.3
to
to
to
to
to
to
to
to
to
to
to
to
to
to
to
to
to
to
to
1.4.1 1.5 1.5.1 1.5.2 1.5.3.1 1.5.4 1.6.0 1.6.1 1.6.2 1.6.3 1.6.4 1.6.5 1.7.0 1.7.1 1.8.0 1.8.1 1.8.2 1.8.3 1.8.4

0
1.1
to
1.2

1.2
to
1.3

1.3
to
1.4

1.4 1.4.1 1.5 1.5.1 1.5.2 1.5.3.1 1.5.4 1.6.0 1.6.1 1.6.2 1.6.3 1.6.4 1.6.5 1.7.0 1.7.1 1.8.0 1.8.1 1.8.2 1.8.3
to
to
to
to
to
to
to
to
to
to
to
to
to
to
to
to
to
to
to
1.4.1 1.5 1.5.1 1.5.2 1.5.3.1 1.5.4 1.6.0 1.6.1 1.6.2 1.6.3 1.6.4 1.6.5 1.7.0 1.7.1 1.8.0 1.8.1 1.8.2 1.8.3 1.8.4

Fig. 6. Change of # of AE Fields in Two Consecutive Versions of Ant

Fig. 7. Change of # of AE Methods in Two Consecutive Versions of Ant

In the same manner, we have analyzed the evolution of AE
method metric. Fig. 7 shows the changes of the number of AE
ﬁelds in two consecutive versions of Ant. Here, the changes
are mostly the addition of the new AE methods, with rarecases of very small decreases in the newer versions.
The major version releases contain many No Access AE ids,
most of which are newly added pub-na. The major version
releases seem to have much more changes than the minor
versions. To conﬁrm this, we have also conducted U test foreach AE id with 5% signiﬁcance level. The differences ofthe major and minor version releases were conﬁrmed for eachAE except for pub-pri, def-pri and def-na, due to their small
numbers of subjects.
The changes of AE ﬁelds and methods might be affected by
the total changes of source code in two consecutive versions.
The correlation coefﬁcient between the source code changes
and the AE ﬁeld changes was 0.85, and that between thesource code changes and the AE method changes was 0.69
(including No Access AE ids). There values are not so high,suggesting that the changes of AE metric values do not simply
reﬂect the source code changes, but they could be used as
independent indicators of the characteristic of major and minor
version releases. We need further investigation of the AE
metric change by tracing each AE ﬁeld and method, and byanalyzing other system evolution to validate this observation.
Answer to RQ2: The AE metric values generally increase
along with the growth of the total system size. Also, thenumbers of some AE ids for ﬁelds and methods are largely
changed at the major version releases, compared to theminor version releases.

methods, which can be accessed from external programs, andalso which will be used in the future. So, she can efﬁciently
identify the AE ﬁelds and methods caused by the bad designand coding, and she can ﬁx those with the correction featureof ModiChecker.
Another use-case of ModiChecker is to validate program
quality at the validation time of system development or maintenance. Program managers and quality managers would run
this tool to see the issues of the access modiﬁers, and theywould explore the overall program quality with the AE metric.
As we have seen in our experiments, we would ﬁnd many
AE ﬁelds and methods. This might be a bad smell of program
quality, but identifying the reasons of AE is not easy for others.
We need to device a method of tracing AE ﬁelds and methods,
and collecting data of future usage of AE ﬁelds and methods,
so that some mechanism of automatic detection of such AE
might be found.
ModiChecker is sufﬁciently fast to do these use-cases,
so that the users can efﬁciently validate and correct theirprograms with the interactive correction feature.
We have used a source-code level analysis approach using
MASU here. We can think another approach of the bytecodelevel analysis. This approach would be easily implemented,
but tracing back from the bytecode information to the sourcecode level would not straightforward.

V. D ISCUSSIONS AND R ELATED W ORK
A. Validity of AE Analysis and ModiChecker Approach
ModiChecker effectively detects and reports issues on theaccessibility excessiveness for the input source programs,
which cannot be detected by ordinary static analysis tools suchas FindBugs [29] or Jlint [30].
A use-case of ModiChecker is that the developer performs
the AE analysis by herself to check the problems on her
code. The developer would easily recognize the AE ﬁelds and

B. Empirical Analysis Results of OSS Systems
As shown in previous section, we have found many AE
ﬁelds and methods in the target systems we have used in our
experiments. The AE metric values generally increase along
the increase of the system sizes. It seems that the developers
add many new AE ﬁelds and methods along the version
evolution without doing serious refactoring to ﬁx the AE ﬁelds
and methods.
Life cycle of AE ﬁelds and methods in the system evolution
would be an interesting research topic. As a partial answer for
this, we have investigated the transition of AE states in RQ1.
Further interest includes the issues such as what is the life
time and who ﬁxed the AE status. To analyze these, we needto trace each AE ﬁeld and method over version history. Thisis an important future work of this research.
To recognize intentional AE ﬁelds and methods for future
use without interviewing the developers is not easy. As asimple estimation method, we can consider the following
approach which could ﬁgure out some part of the excessiveﬁelds/methods for future use, using test programs associatedwith the target program.
The ﬁrst step is checking the source ﬁles without test
programs and we get the result of ModiChecker for the target
program itself. Then we add the test programs and check them
together without counting the ﬁelds/methods in test programs.
The AE ﬁelds/methods found in the ﬁrst step but not in thesecond step could be the ﬁelds/methods for future use, since
they were actually accessed by the objects of test programs.
The test designer anticipated that those ﬁelds/methods shouldbe access from outside the program in the future.
C. Threat to Validity
In our approach, we have used a static analysis method forJava source programs. This approach has a fundamental issue
such that reﬂection code in Java cannot be analyzed correctly.
This is not only our own issue but other static analysis
approaches, including bytecode level static analysis, containthis issue. However, even with such limitation, the results
obtained from ModiChecker and its AE analysis are very
useful information to the program developers and maintainers.
We would think of dynamic analysis approach for the
AE analysis [5], [18]. The dynamic analysis is performedby collecting execution traces, and by analyzing them forspeciﬁc objectives. This approach would solve the issue ofthe reﬂection easily, but the weakness of the dynamic analysis
still remains. In the dynamic analysis, we have to choose
appropriate test executions to cover practical use-cases of thetarget program. Without such consideration, the result would
be partial and it cannot be generalized. Another issue is tohandle large amount of execution trace data efﬁciently. To
handle the target programs with practical sizes, we need todevise some compaction method to reduce the execution trace
sizes [13], [19].
In our experiments, we have used seven OSS systems toknow the characteristics of AE and the AE metric. These
would be insufﬁcient to get general consequence, especiallyon the case of evolution pattern of the AE metric, which was
obtained only from Ant’s 22 versions. We will continue toanalyze various OSS systems, as well as proprietary industry
systems developed under some organizational development
disciplines. It would be considered that such disciplined development would create less AE ﬁelds and methods, but we needvalidation with some data of proprietary industry systems.
D. Related Work
Access Modiﬁer Analysis: There are some previous works
related to ours. Müller has proposed bytecode analysis forchecking Java access modiﬁers [11]. They have developed atool named AMA (Access Modiﬁer Analyzer), which analyzes
Java bytecode for the similar objectives of ours. However, thebytecode level analysis for the ﬁelds and methods does notalways correspond to the source code level analysis, due tothe extra ﬁelds and methods added at the compilation time.
Also, they have reported no empirical results of using theirtool. In this paper, we have clearly deﬁned the concept of AE,
and shown the empirical results with several target systems.
Tai Cohen studied the distribution of the number of eachJava access modiﬁer in some sample methods [4]. Security
vulnerability analysis has been studied using static analysis
approaches [6]. Among these researches, an issue of accessmodiﬁer declaration has been discussed by Viega et al. [21],where a prototype system Jslint has been presented without
any detailed explanation of its internal algorithm and architecture. Also, Jslint only gives warning for the ﬁelds/methods
which are undeclared private, while our tool supports all kindsof access modiﬁer declarations based on analyzing actual
usage.
Vidal et al. have empirically studied similar AE analysis
to Java open-source software, and found that at least 20% of
deﬁned methods are over-exposed, and 70% of the methods ofsubject applications are deﬁned as public [20]. They also foundthat libraries have on average more over-exposed methods thanplain applications, less than 10% of the over-exposed methods
deﬁned in early versions of the applications become non-overexposed in future versions.
The idea of using access modiﬁer metrics would be related
to our previous work [9]. In that paper, the number of eachJava access modiﬁer is used as one of the metrics for checking
the similarity between Java source codes.
Static Code Analyzers: There are a lot of static codeanalysis tools for Java [29], [30]. Those tools are very popular these days in the development of Java programs. Theyﬁnd possible bugs or bad coding patterns such as deadlock,overloading, array boundary overﬂow, and so on. Rutar et. al.
have compared ﬁve of those tools, and reported the difference[14]. However, none of these tool currently available publicly
or commercially have the feature for analyzing the AE ﬁelds
and methods.
Static Code Analysis for Object Oriented Languages: Analyzing actual usage of ﬁelds and methods are related to various
static analysis techniques of object oriented languages, such as
reference analysis, point-to analysis, call graph analysis, andclass analysis. Reference analysis and point-to analysis are
static methods for identifying reference objects of a pointeror variable [1], [10], [17]. It is based on the control ﬂow
and data ﬂow analyses, and also context sensitivity or ﬂow
sensitivity of method calls is used [22]. In our AE analysis,
MASU provides information of possible reference of ﬁelds,
which would be considered as a simple point-to analysis.
Call graph analysis is a method to establish caller and callee
relations for the given program [7]. There are many traditionin ordinary programming languages, and also many methods
have been proposed and actually implemented as tools forthe object oriented languages [25], [26], [28]. In MASU, thecaller-callee relations is constructed by estimating possible
candidate callees for each method invocation.

These analyses in object oriented languages need a basis ofclass analysis, which determines the classes of the objects towhich reference variables may point. This is a fundamental
analysis so that there are many research works presented [7],[15]. MASU performs this analysis as a part of other analyses
mentioned above.
VI. C ONCLUSIONSModiChecker has been used to analyze many OSS systems
to investigate our approach with two research questions. The
analysis results show the characteristics of AE ﬁelds andmethods, including their transition and evolution.
We have found that our system is very useful to detect ﬁelds
and methods with the excessive access modiﬁers, and that
there are many AE ﬁelds and methods with various reasons
including bad design and coding. According to the result of
AE analysis for software evolution, we also found that the
number of AEs increases when the major version was released.
We understood that it would be better for developers that theywould like to check AEs before releasing new major version,
to ﬁnd out potential bugs effectively. We are conﬁdent that
the AE analysis with ModiChecker is an important method to
support quality programming and understanding in Java.
Throughout the experiments, we found that there are two
types of AEs, AEs by design or coding errors, and intentional
AEs for further extensions or accesses from external software.
Our tool has a feature to opt-out intentional AEs manually tocope with the situation. As the further work, we are developinga mechanism to detect intentional AEs automatically, by
analyzing class diagrams or test codes of target source codes.
Investigating abstract classes would also be needed to clarify
how many AEs are in existing software. Interviewing softwaredevelopers to ask why/how they create and resolve AEs in theirsoftware would also be an interesting further direction of thisresearch.
ACKNOWLEDGMENT
The authors would like to thank to Quoc Dotri who contributed to the initial development of ModiChecker. Also, we
would like to thank to Tatsuya Ishizue and Riku Ohnishi forthe support to this work. This work is partially supported by
Japan Society for the Promotion of Science, Grant-in-Aid for
Scientiﬁc Research (S) (No.25220003) and Osaka University
Program for Promoting International Joint Research.
R EFERENCES[1] L. Andersen, “Program Analysis and Specialization for the C Programming Language”, Ph.D. thesis, DIKU, University of Copenhagen, 1994.
[2] K. Arnold, J. Gosling and D. Holmes, “The Java Programming Language, 4th Edition”, Prentice Hall, 2005.
[3] G. Booch, R.A. Maksimchuk, M.W. Engel, B.J. Young, J. Conallen
and K.A. Houston, “Object-Oriented Analysis and Design with Applications”, Addison Wesley, 2007.
[4] Tal Cohen, “Self-Calibration of Metrics of Java Methods towards the
Discovery of the Common Programming Practice”, The Senate of theTechnion, Israel Institute of Technology, Kislev 5762, Haifa, 2001.
[5] B. Cornelissen, A. Zaidman, A. van Deursen, L. Moonen and R.
Koschke, “A Systematic Survey of Program Comprehension throughdynamic Analysis”, IEEE Tran. on Software Engineering, Vol. 35, No. 5,
pp.684–702, 2009.

[6] D. Evans, and D. Larochells, “Improving Security Using Extensible
Lightweight Static Analysis”, IEEE software, vol.19, No.1, pp. 42-51,
Jan/Feb 2002.
[7] D. Grove, and C. Chambers, “A Framework for Call Graph Construction Algorithms”, ACM Transactions on Programming Languages andSystems (TOPLAS), Vol. 23, No. 6,pp. 685–746, 2001.
[8] Y. Higo, A. Saito, G. Yamada, T. Miyake, S. Kusumoto, and K. Inoue,“A Pluggable Tool for Measuring Software Metrics from Source Code”,
The Joint Conference of the 21th International Workshop on Software
Measurement and the 6th International Conference on Software Process
and Product Measurement (IWSM-MENSURA), Nara, Japan, pp.3–12,
Nov. 2011.
[9] K. Kobori, T. Yamamoto, M. Matsushita , and K. Inoue, “Java Program
Similarity Measurement Method Using Token Structure and Execution
Control Structure”, Transactions of IEICE , Vol. J90-D No.4, pp. 1158–
1160, 2007 (in Japanese).
[10] A. Milanova, A. Rountev, and B. Ryder, “Parameterized Object Sensitivity for Points-to Analysis for Java”, ACM Transactions on Software
Engineeing and Methodology, Vol. 14, No. 1, pp. 1-41, 2005.
[11] A. Müller, “Bytecode Analysis for Checking Java Access Modiﬁers”,
Work in Progress and Poster Session, 8th Int. Conf. on Principles andPractice of Programming in Java (PPPJ 2010), Vienna, Austria, 2010.
[12] D. Quoc, K. Kobori, N. Yoshida, Y. Higo and K. Inoue, “ModiChecker:
Accessibility Excessiveness Analysis Tool for Java Program”, 28th
National Convention of Japan Society for Software Science and Technology, Vol. 28, pp. 78-83, Nara, Japan, 2011.
[13] S. Reiss, and M. Reniers, “Encoding Program Executions”, 23rd International Conference on Software Engineering, pp. 221–230, Toronto,
Canada, 2001.
[14] N. Rutar, C. Almazan, and J. Foster, “ A Comparison of Bug Finding
Tools for Java”, 15th International Symposium on Software Reliability
Engineering (ISSRE 04), pp. 245– 256, Saint-Malo, France, 2004.
[15] B. Ryder, “Dimensions of Precision in Reference Analysis of ObjectOriented Programming Languages”, 12th International Conference on
Compiler Construction, pp. 126–137,Warsaw, Poland, 2003.
[16] A. Saito, G. Yamada , T. Miyake, Y. Higo, S. Kusumoto and K.
Inoue, “Development of Plug-in Platform for Metrics Measurement”,
International Symposium on Empirical Software Engineering and Measurement, Poster Presentation, Lake Buena Vista, 2009.
[17] B. Steensgaard, “Points-to analysis in almost linear time”, 23rd ACM
SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pp. 32–41, St. Petersburg, FL, 1996.
[18] T. Systa, “Understanding the Behavior of Java Programs”, 7th Working
Conference on Reverse Engineering, pp.214-223, Brisbane, Australia,
2000.
[19] K. Taniguchi, T. Ishio, T. Kamiya, S. Kusumoto and K. Inoue, “Extracting Sequence Diagram from Execution Trace of Java Program”, 8thInternational Workshop on Principles of Software Evolution (IWPSE
2005), pp.148-151, Lisbon, Portugal, 2005.
[20] S. A. Vidal, A. Bergel, C. Marcos and J. A. Dı́az-Pace, “Understanding
and Addressing Exhibitionism in Java Empirical Research about Method
Accessibility”, Technical Report of Departamento de Ciencias dela Computación, http://swp.dcc.uchile.cl/TR/2014/TR DCC-20141204004.pdf.
[21] J. Viega, G. McGraw, T. Mutdosch and E. Felten, “Statically ScanningJava Code: Finding Security Vulnerabilities”, IEEE software, Vol.17 No.
5 pp. 68-74, Sep/Oct 2000.
[22] R. Wilson, “Efﬁcient Context-Sensitive Pointer Analysis for C Program”,
Ph.D. Thesis, EE Dept., Stanford University, 1997.
[23] Ant, http://ant.apache.org/.
[24] ANTLR, http://www.antlr.org/.
[25] cﬂow, http://www.gnu.org/software/cﬂow/.
[26] CodeViz, http://www.csn.ul.ie/ mel/projects/codeviz/.
[27] Controlling Access to Members of a Class, The Java Tutorials,
http://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html .
[28] Doxygen, http://www.stack.nl/ dimitri/doxygen/.
[29] FindBugs, http://ﬁndbugs.sourceforge.net/.
[30] Jlint, http://jlint.sourceforge.net/.
[31] MASU, http://sourceforge.net/projects/masu/.

All company names, brand names, service names, and product names thatappear throughout this paper are trademarks or registered trademarks of theirrespective companies.