212

ModiChecker: Accessibility Excessiveness
Analysis Tool for Java Program
Dotri Quoc

Kazuo Kobori

Yoshiki Higo

Katsuro Inoue

Norihiro Yoshida

In object-oriented programs, access modifiers are used to control the accessibility of fields and methods
from other objects. Choosing appropriate access modifiers is one of the key factors for easily maintainable
programming. In this paper, we propose a novel analysis method named Accessibility Excessiveness (AE)for each field and method in Java program, which is discrepancy between the access modifier declarationand its real usage. We have developed an AE analyzer - ModiChecker which analyzes each field or methodof the input Java programs, and reports the excessiveness. We have applied ModiChecker to various Java
programs, including several OSS, and have found that this tool is very useful to detect fields and methods
with the excessive access modifiers.

1 Introduction
To realize good encapsulation in Java programs,
we have to choose appropriate access modiﬁers of
methods and ﬁelds in a class, which may be possiblyaccessed by other objects. However, inexperienced
developers tend to set all of the access modiﬁers
public or none as default indiscriminately.
For example, Figure 1 is a case of bad accessmodiﬁer setting. Suppose that we have 2 methods: Method A and Method B in class X. Method
A keeps an initialization process for Method B. It
means 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 the access modiﬁer of Method
B should be set private. However, a novice developer might set that access modiﬁer public without
ModiChecker :Java プログラムのアクセス修飾子過剰性
分析ツール.
Dotri Quoc, 小堀一雄, 肥後芳樹, 井上克郎, 大阪大学大学
院情報科学研究科コンピュータサイエンス専攻, Dept. ofComputer Science, Graduate School of Information
Science and Technology, Osaka University.
吉田則裕, 奈良先端科学技術大学院大学情報科学研究
科, Graduate School of Information Science, Nara
Institute of Science and Technology.
コンピュータソフトウェア, Vol.29, No.3 (2012),pp.212–218.
[研究論文 (レター)] 2011 年 10 月 20 日受付.

thinking seriously. In a meanwhile, other developer
would want to use Method B and he/she can 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 performedby Method A.
In this example, the access modiﬁer of Method B
is public, but the current program accesses Method
B from private method (Method A only in thiscase) and the access modiﬁer of Method B should
be private. Such discrepancy between the declared
accessibility and actual usage of each method andﬁeld is called Accessibility Excessiveness(AE) here.
Existence of AE would be a bad smell of program, and it would indicate various issues on thedesigns and developments of program as follows.
(1) Immature Design and Programming Issue:
An AE would cause unwilling access to a method or

Fig. 1

Inappropriate
Declaration

AccessModifierVol. 29 No. 3 Aug. 2012
ﬁeld which should not be accessed by other objects
in a latter development or maintenance phases asshown in the example. This is an issue of designand development processes from the view point of
encapsulation [1]. This problem shows the immaturity and carelessness of the designer and developer.
(2) Maintenance Issue: Sometimes developer intentionally set ﬁeld or method excessive for future
use or for the purpose of being called from outsiders. It is not easy to distinguish whether AE isintentionally set by developer or it is a case of Issue
1, so that the maintenance of such program is notstraightforward and complicated.
(3) Security Vulnerability Issue: A program withAE has potential vulnerability of its security inthe sense that an attacker may access an AE ﬁeld
and/or method against the intention of the program designer and developer [2].
In this paper, we discuss on an AE analysis
method mostly focusing on its application to Issue 1 and 2, and Issue 3 will be a further research
topic.
We propose an AE analysis tool named
ModiChecker, which takes a Java program as input,
then analyzes and reports the excessiveness of eachaccess modiﬁer declared for each method and ﬁeld.
ModiChecker is based on static program analysis
framework MASU [6][7][8], which allows a ﬂexible
composition of various analysis tools very easily.
Using ModiChecker, we have analyzed several open source software(OSS) such as Ant andjEdit. Also, MASU itself has been analyzed by
ModiChecker. The analysis results show that some
OSS contain many AE methods and ﬁelds, whichshould be set to more restrictive access modiﬁers.
There are some previous works related to ours.
Tai Cohen studied the distribution of the number of
each Java access modiﬁer in some sample methods[3]. Security vulnerability analysis has been studied
using static analysis approaches [4]. Among theseresearches, an issue of access modiﬁer declaration
has been discussed by Viega et al. [2], where a prototype system Jslint has been presented without
any detailed explanation of its internal algorithm
and architecture. Also, Jslint only gives warning forthe ﬁelds/methods which are undeclared private,while our tool supports all kinds of access modiﬁer
declarations based on analyzing actual usage.
In the following, we will deﬁne AE in Section 2.

Table 1

213
Accessibility Excessiveness Map

Section 3 describes ModiChecker and MASU. In
Section 4, we will show our experimental results.
Section 5 will conclude our discussions with a few
future works.

2 Accessibility Excessiveness Map
Table 1 is called Accessibility Excessiveness Map(AE map), which lists all the cases where an AE
happens. The vertical column shows the declaration of an access modiﬁer for a method or ﬁeld inthe source code. The horizontal row shows its actual usage from other objects. Each element in AE
map is an AE Identifier (AE id) which identiﬁes
each AE case. For example, if a method has public
as the declaration of the access modiﬁer, and it isaccessed only by the objects of same class, the AE
id is “pub3” meaning it could be set to private.
Note that “default” means the case that there is
no explicit declaration of the access modiﬁer and itis the same as package.
An AE id “ok-xxx” means that there is no discrepancy between the declaration and actual usage,and it is an ideal way of quality programming. An
AE id “x” means that these cases are detected as
error at the compilation time and they are out of
the scope of the AE analysis. An AE id in shaded
cells means that the declaration is excessive one
from the actual usage of the access modiﬁer.
Purpose of the AE analysis is to identify an AE
id for each method and ﬁeld in the input sourcecode. Also, we are interested in the statistic measures of AE ids for the input program, which would
be important clues of program quality.

3 AE Analysis Tool ModiChecker
3. 1 Approach to AE Analysis
To perform the AE analysis, we need to know thedeclaration of the access modiﬁers of each method
and ﬁeld of the input program. This is easily doneby parsing the program. Also, we have to investigate into the actual usage of each method and ﬁeld.

214

コンピュータソフトウェア

For this work, we employ a static source-code analysis, which identiﬁes other classes that may possibly access the target method or ﬁeld. For these
purposes, we have used a Java program analysis
framework MASU [6][7][8].
MASU has been originally designed to implement
pluggable multi-purpose metrics infrastructure, but
it is very useful as a Java program analysis framework. MASU transforms the input Java program
into an Abstract Syntax Tree (AST), and then it
analyzes AST for actual usage of the methods andﬁelds in the input.
ModiChecker is a system with 521 source ﬁles and102,250 LOC in Java, developed based on MASU
framework [8]. MASU framework itself accounts for519 source ﬁles and 102,000 LOC in Java (41,000
LOC are automatically generated code by ANTLR[9]).
3. 2 Overview of ModiChecker
Architecture
Figure 2 shows the architecture of ModiChecker.
Firstly, ModiChecker reads source program and allof the required library ﬁles (normally, the libraryﬁles are often in .jar ﬁles) in Java. The source codeis transformed to an AST associated with various
static code analysis results.
After analyzing source, we get the access modiﬁer declaration and also usage of each ﬁeld andmethod. From the AST database, we can easily
know which class may access that method/ﬁeld.
By comparing the declaration of the access modiﬁer and real usage of the ﬁeld and method,
ModiChecker reports AE for each ﬁeld and method.
ModiChecker treats some special cases as follow:• ModiChecker does not give any report formethods of abstract classes or interfaces because they are overridden by the method ofother classes. One more reason is that an abstract class or interface does not generate any
object so that its methods will never be called
and those access modiﬁers do not aﬀect maintenance processes.
• In the case of a method overriding anothermethod, the overriding method in a subclassmust have an access modiﬁer with an equal
or more permissive level to the access modiﬁer of the overridden method. ModiChecker
detects such an overriding method and reports

Fig. 2

Fig. 3

Architecture of ModiChecker

Access Modifier of Overriding Method

an AE id between the access modiﬁer of theoverridden method and its actual usage. For
example, in Figure 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 report private for
Method B.C even if Method B.C is actuallyused inside Class B only. In dynamic binding cases, if a class accesses a method of a superclass, ModiChecker will consider that classalso accesses the method of all subclasses ofthe superclass. By this way, dynamic bindingcases should not bring about any bad eﬀect to
ModiChecker analysis result.

4 Experiments and Discussions
4. 1 Overview
We have conducted case studies with some opensource code projects to evaluate the AE analysis.
In the evaluation, we have focused on the following
points.
• The total number of each AE id is measured
to evaluate how program is well designed.
• Based on the above result, we have closelyVol. 29 No. 3 Aug. 2012
Table 2Size and Running Time of Target

Table 3 Number of Detected AE ids for
Fields in MASU

Table 4 Number of Detected AE ids for
Methods in MASU

investigated the reasons of setting the accessmodiﬁers excessively. Sometime an accessmodiﬁer would be intentionally set excessively
by the developers for the future purpose, orsometime they would be set excessively by automatic code generator.
The target software products are 3 Java programs: MASU, Ant 1.8.2, jEdit 4.4.1.
We did these experiments on a PC workstation
with the speciﬁcation of OS : Windows 7 Enterprise 64bit, CPU : Intel Xeon 5160(3.00 GHZ, 2processors), Memory: 8.0 GB.
Table 2 shows the size and running time of eachexperiment.
4. 2 Experiment Result
4. 2. 1 MASU
By analyzing MASU, we got the number of detected AE ids as shown in Table 3 and Table 4.
We have found 280 ﬁelds with the excessive accessmodiﬁers. Out of these 280 ﬁelds, 255 ﬁelds wereidentiﬁed as automatically generated code by ourhand-analysis. We have interviewed the developerof MASU and asked the reason of the excessivenessof other ﬁelds. 20 ﬁelds have been found that they215

Table 5 Number of Detected AE ids for
Fields in Ant

Table 6 Number of Detected AE ids for
Methods in Ant

are intentionally set excessively for future uses. Finally, 5 ﬁelds have been identiﬁed actually excessive and those access modiﬁers have been changed
to proper ones.
We have also found 253 methods with the excessive access modiﬁer. And by our hand-analysis, 6
methods were found to be automatically generated
code. Out of those 253 methods, 181 methods areintentionally set excessively for future uses. Finally,
66 methods have been identiﬁed actually excessive
and those access modiﬁers have been changed toproper ones.
4. 2. 2 Ant 1.8.2
We have investigated into the newest version of
Ant 1.8.2 and got the number of detected AE ids forﬁelds and methods as shown in Table 5 and Table
6.
We have found 611 ﬁelds and 1520 methods
with the excessive access modiﬁers. By our handanalysis, we were unable to ﬁnd any ﬁeld withexcessive access modiﬁer generated by some automatic code generator.
Looking at the ratio of excessive access modiﬁer, the ratio of excessive ﬁelds is 18.9%(shownin the shaded cells in Table 5) while ratio of excessive methods is 35.5%(shown in shaded cells in
Table 6). Since a standard design strategy might
be to make all ﬁelds private and to provide public
getter/setter methods for them, methods has moreprobability to be set excessively for future use thanﬁelds. That would be the reason why the ratio ofexcessive methods is higher than ratio of excessiveﬁelds.

216

コンピュータソフトウェア

Table 7 Number of Detected AE ids for
Fields in jEdit

Table 8 Number of Detected AE ids for
Methods in jEdit

4. 2. 3 jEdit 4.4.1
The result of detected AE ids for ﬁelds and methods for jEdit 4.4.1 is shown in Table 7 and Table
8.
For jEdit, we have found 604 ﬁelds and 981 methods with the excessive access modiﬁers. We wereunable to ﬁnd any ﬁeld or method with excessiveaccess modiﬁer generated by some automatic code
generator by our hand-analysis.
For jEdit 4.4.1, the ratio of excessive ﬁelds is
24.5%(shown in the shaded cells in Table 7) while
the ratio of excessive methods is 30.4%(shown inthe shaded cells in Table 8). Like the case of Ant
1.8.2 shown above, the ratio of excessive ﬁelds islower than the ratio of excessive methods.
4. 3 Discussions
To validate the analysis result of ModiChecker,
we have changed all the excessive access modiﬁers
of above three programs to suggested access modiﬁers. All the modiﬁed programs have been compiled and executed without any error. This indicates that the output report of ModiChecker isproper one in the sense that the reported excessiveaccess modiﬁers can be changed to more restrictive
access modiﬁers without causing any error.
As mentioned before, our tool gives the developer
the AE analysis result for each ﬁeld/method in thecurrent target program, but it still can not makesure that some of them were intentionally set excessive for future use. Only designer and developer
can identify that those ﬁelds/methods are really ex-cessive or not. Thus, we need a tool by which adeveloper can select each access modiﬁer found as
excessive and to be changed to more restrictive one
by her/his decision.
By using AE analysis, we could propose quality
metrics in the following ways.
• We set a value called AE index for each AE id
and sum up each AE index as metrics value.
• We set a value for each method and ﬁeld basedon the number of other classes accessing thoseﬁelds and methods. Those values for eachmethod/ﬁeld are accumulated as this metrics
value.
These metrics would indicate bad smell of program such as immaturity of design and implementation, low maintainability, security vulnerability,
and so on. We need further experiments for thevalidation of eﬀectiveness of such metrics.
The idea of using access modiﬁer metrics would
be related to our previous work [5]. In that paper,
the number of each Java access modiﬁer is used as
one of the metrics for checking the similarity between Java source codes.
To recognize intentional AE ﬁelds/methods for
future use without interviewing developers is noteasy. As a simple estimation method, we propose
the following approach which can ﬁgure out somepart of the excessive ﬁelds/methods for future use,
using test ﬁles associated with the target program.
The ﬁrst step is checking the source ﬁles without test ﬁles and we get the result of ModiChecker
for the target program itself. Then we add thetest ﬁles and check them together without counting the ﬁelds/methods in test ﬁles. The excessiveﬁelds/methods found in the ﬁrst step but not in thesecond step could be the ﬁelds/methods for futureuse, since they were actually accessed by the objects of test ﬁles. The test designer anticipated thatthose ﬁelds/methods should be access from outside
the program in the future.
In this experiment we have not counted forthe ﬁelds/methods which are not accessed byany objects (we would like to call them no access ﬁelds/methods). The reason of no accessﬁelds/methods might be developers’ carelessness
and intentional future use. Investigating into noaccess ﬁelds/methods would be an interesting future research topic.

Vol. 29 No. 3 Aug. 2012

5 Conclusions
In this paper, we have proposed an analysis
method named AE for each ﬁeld and method inJava program, which is discrepancy between an access modiﬁer declaration and the real usage of theﬁeld and method. We have also introduced AE Map
which lists all of the cases where an AE happens.
We have developed a tool named ModiChecker,
which ﬁnds excessive method/ﬁeld and reports AE
id of each excessive method/ﬁeld. We have also
used ModiChecker to analyzed several OSS such as
MASU, Ant, jEdit, and found that our system isquite useful to detect ﬁelds and methods with theexcessive access modiﬁers.
Since there is no other tool to analyze accessmodiﬁers as discussed here, we think ModiChecker
will be an important tool to support quality programming in Java.
Currently we are analyzing other Java programs
including industrial systems, and are trying to identify the relation between the AE analysis results
and other program quality indicators such as bug
frequency.

217

Method Using Token Structure and Execution Control Structure, Transactions of IEICE, Vol. J90-D
No. 4 (2007), pp. 1158–1160.
[ 6 ] Higo, Y., Saito, A., Yamada, G., Miyake, T.,
Kusumoto, S. and Inoue, K.: A Pluggable Tool
for Measuring Software Metrics from Source Code,in The Joint Conference of the 21th International
Workshop on Software Measurement and the 6thInternational Conference on Software Process andProduct Measurement, 2011 (to appear).
[ 7 ] Saito, A., Yamada, G., Miyake, T., Higo, Y.,
Kusumoto, S. and Inoue, K.: Development of Plugin Platform for Metrics Measurement, in International Symposium on Empirical Software Engineering and Measurement, Poster Presentation, Lake
Buena Vista, 2009.
[ 8 ] MASU, http://sourceforge.net/projects/masu/[ 9 ] ANTLR, http://antlr.org[10] Ant, http://ant.apache.org[11] jEdit, http://jedit.org

Dotri Quoc
2005 年ベトナムの郵政電信工芸学院(Institute of Posts and Telecommunications Technology) に入学，2007
年同大学中退．2008 年大阪大学基礎

Acknowledgements This work is supported
by JSPS, Grant-in-Aid for Scientiﬁc Research (A)(No. 21240002) and Grant-in-Aid for Exploratory
Research (No. 23650015). This is also supported
by MEXT Stage Project, the Development of Next
Generation IT Infrastructure.

工学部情報科学科入学，2012 年卒業．現在楽天 (株)に所属．日本ソフトウェア科学会会員．
小堀一雄

1979 年生．2005 年大阪大学大学院
情報科学研究科修士課程修了．同年

References[ 1 ] Booch, G., Maksimchuk, R.A., Engel, M.W.,
Young, B.J., Conallen, J. and Houston, K.A.:
Object-Oriented Analysis and Design with Applications, Addision Wesly, 2007.
[ 2 ] Viega, J., McGraw, G., Mutdosch, T. and Felten, E.: Statically Scanning Java Code: Finding
Security Vulnerabilities, IEEE software, Vol. 17 No.
5(2000) pp. 68–74.
[ 3 ] Cohen, T.: Self-Calibration of Metrics of Java
Methods towards the Discovery of the Common Programming Practice, The Senate of the Technion,
Israel Institute of Technology, Kislev 5762, Haifa,
2001.
[ 4 ] Evans, D. and Larochells, D.: Improving Security Using Extensible Lightweight Static Analysis,IEEE software, Vol. 19, No. 1(2002), pp. 42–51.
[ 5 ] Kobori, K., Yamamoto, T., Matsushita, M. andInoue, K.: Java Program Similarity Measurement(株)NTT データ入社．ソフトウェア
テストやソフトウェアプロセスの研究に従事．2010 年大阪大学大学院情報科学研究科博士課程入学．
吉田則裕

2004 年九州工業大学情報工学部知能情報工学科卒業．2009 年大阪大学大学院情報科学研究科博士後期課程修了．2010 年奈良先端科学技術大学院
大学情報科学研究科助教．博士 (情報科学)．コード
クローン分析手法やリファクタリング支援手法に関する研究に従事．ソフトウェア科学会，情報処理学会，

218

コンピュータソフトウェア

電子情報通信学会，人工知能学会，IEEE，ACM 各
会員．

井上克郎

1984 年大阪大学大学院基礎工学研究肥後芳樹

2002 年大阪大学基礎工学部情報科学科中退．2006 年同大学大学院博士後期課程修了．2007 年同大学大学院情報科学研究科コンピュータサイエン
ス専攻助教．博士 (情報科学)．ソースコード分析，特にコードクローン分析やリファクタリング支援に関する研究に従事．日本ソフトウェア科学会，情報処理学会，電子情報通信学会，IEEE 各会員．

科博士後期課程修了 (工学博士)．同年，大阪大学基礎工学部情報工学科
助手．1984〜1986 年，ハワイ大学マノア校コンピュータサイエンス学科助教授．1991 年大阪大学基礎工学部助教授．1995 年同学部教授．2002
年大阪大学大学院情報科学研究科教授．2011 年 8 月
より同研究科研究科長．ソフトウェア工学，特にコー
ドクローンやコード検索などのプログラム分析や再利用技術の研究に従事．