Lecture Notes on Software Engineering, Vol. 2, No. 2, May 2014

Managing Product Variants by Project Centralization
Lei Ma, Cyrille Artho, and Hiroyuki Sato

variability that is usually represented as a feature model.
However, this needs domain analysis to identify features andestablish the connections between a feature and its
corresponding code, which proves to be difficult to automate
and lacks accuracy [11], [2]. On the other hand, as a main
challenge of software management using a revision control
system, we must resolve version conflicts when merging
existing products [8]. A version control system usuallyadopts a text-based comparison to track changes so thatdifferent types of documents can be handled. However, theunawareness of underlying language structure hinders further
analysis for the multiple product variants by existing tools.
Although some language structure-aware merging strategies
have been developed to handle different languages, thesetechniques do not guarantee to preserve the behavior of eachproduct [9], [10].
In our previous work [4], we have proposed project
centralization to resolve version conflicts of multiple productvariants in a distributed system. It enables the analysis andverification of the system as a whole by existing tools likeJava PathFinder [12]. Project centralization represents thecode repositories of all product variants using a single
centralized repository while preserving the behavior of eachoriginal.
In this paper, we report our preliminary study to explore
the usefulness of project centralization for managing multiple
product variants to avoid code duplication while preserving
the behavior of each product. We perform case studies on
three real-world Java applications, containing 10 variants foreach application with over two million lines of code in total,
to demonstrate the feasibility of project centralization for
managing similar product variants and to point out directions
for future research. While our implementation supports Java
bytecode, the concepts presented in this paper generalize toother managed programming languages and runtime
platforms.
The rest of this paper is organized as follows: Section II
first illustrates the basic concepts of project centralization.
Then, we summarize two project centralization algorithms
published earlier [4]. Section III reports on our case studies
where we apply our tool to real-world nontrivial projects.
After discussing related work in Section IV, Section V
concludes and presents future work.

Abstract—Many software systems are evolving continuously.
The changes are reflected in a sequence of revised products,
including both version updates and related product variants
that are created by the clone-and-own approach. Separate
management and analysis of these product variants waste
storage and hinders uncovering their commonalities andvariations for maintenance. In this paper, we explore theproject centralization approach to manage product variants.
Our technique shares common code whenever possible while
keeping the version space of each project separate. We present
the key issues of project centralization and its algorithms. We
perform several case studies, where project centralization isapplied to real-world software projects, demonstrating thepotential usefulness of our approach.
Index Terms—Software evolution, software management,
project centralization, multiple versions, program analysis.

I. INTRODUCTION
A software system continuously changes to increase its
functionality, fix bugs, and adapt to new requirements over
its life cycle [1]. Such changes are released as a sequence of
updated revisions. Some related product variants are also
created by coping and modifying existing ones (theclone-and-own approach), which is a common practice fordeveloping new software products [2]. As many similar
product variants are developed, management and analysis ofthese products effectively becomes very important.
Managing each of these products separately wastes storage
by code duplication and causes redundancies for analysis andverification. For example, if a function under test exists in
multiple products with both the same implementation andruntime behavior, independently exercising the same test
case for such a function for each product causes redundant
executions [3]. If multiple variants of a software systeminteract in a distributed system, analysis and verification ofthese applications also create a challenge in representing
these multiple versions for analysis tools and execution
platforms like Java and C#, which are designed to handle
only single version [4] .
Several strategies have been proposed to manage multiple
variants of a software system during the past decades. Someadvocates refactor them into Software Product Lines (SPL)[5]-[7], and many others manages them in a revision control
system [8]-[10]. A difficulty of refactoring multiple similar
product variants into a SPL is to extract the commonality and

II. PROJECT CENTRALIZATIONIn this section, we present the concepts related to project
centralization. We consider sharing common code on a classfile level (without merging files).

Manuscript received September 25, 2013; revised November 26, 2013.
This work was supported in part by Global COE Secure-Life Electronics
Program from the University of Tokyo, Japan.
Lei Ma and Hiroyuki Sato are with the Department of ElectricalEngineering,the
UniversityofTokyo,
Japan(e-mail:malei@satolab.itc.u-tokyo.ac.jp, schuko@satolab.itc.u-tokyo.ac.jp).
Cyrille Artho is with the Research Institute for Secure Systems, AIST,Japan (e-mail: c.artho@aist.co.jp).

DOI: 10.7763/LNSE.2014.V2.122

A. Concepts and Definitions
A Java class is uniquely identified by its name andimplementation. For a class cl, we use cl.name and cl.code to195

Lecture Notes on Software Engineering, Vol. 2, No. 2, May 2014

denote its name and implementation, respectively. Given twoclasses cl1 and cl2, we say they are equivalent, denoted by
cl1=cl2, if they form a Type-1 clone pair [13], where cl1.nameand cl2.name are identical, and cl1.code and cl2.code are also
identical except for variations in whitespace, layout andcomments.
A project is a set of classes, where no two classes in a
project share the same name. Let p be a project. We denotethe number classes of p by #p. We write NAME(p) as the setof all class names in p. A project presents an abstract view of
the class repository of a software product.
Definition 1. Let cln1 and cln2 be two class names. Project
renaming substitution p[cln1/cln2] is defined as a project,
where cln1 is substituted for cln2 in p. A renaming
substitution for p is a normal substitution if cl1NAME(p)and cl2NAME(p).
Definition 2. Let p1 and p2 be two projects. The behaviorsof p1 and p2 are equivalent, denoted by p1 = p2, if they can berenamed to an identical project by normal renaming
substitutions.
Definition 3. Project centralization of a project set P
transforms P into a single project pcentra such that pP.
p pcentra . p = p. We denote all the centralized results of P
that satisfy such a condition by CENTRA(P).
Project centralization represents multiple projects by one
centralized project, entailing each original project preserves
its behavior after centralization. Let cl1 and cl2 be two classes
in a project p. Class cl1 depends on cl2, denoted by cl2  cl1,
if cl1.code references cl2.name. If class cl1 and cl2 have adependency relation cl1  cl2 and cl1 is renamed, allreferences of cl1 in cl2 must also be renamed to preserve thebehavior. Let p1 and p2 be two projects. The behaviors of p1
and p2 are equivalent if they can be renamed to an identicalproject by normal renaming substitutions.
We use the A.D. value to measure the average complexityof the reference dependencies for all projects in a project set.
Definition 4. Let P be a project set. The Average
Dependency (A.D.) of P is defined as:å
A.D. =

pÎP#{(cl1, cl2 ) | cl1, cl2 Î p Ù cl1 ® cl2 }#P

to retain shared classes as much as possible.
B. Example
Fig. 1 shows an example for centralizing three projects.
The edges in a project represent the class dependencies. For
example, the edge from class A to B in Project1 shows thatthey have the dependency relation A B. Project1 andProject2 share most of the classes except for C where
different versions are used. Compared with Project2, Project3
has a different version of Main and a new class Unique. In
this example, class A and B are shared classes in all projects.
The cases for classes C and Main are more complex: the class
C is a conflict class in Project1, but it is both a shared andconflict class in Project2 and Project3. Similarly, class Mainin Project3 is a conflict class, and it is both a shared andconflict class in Project1 and Project2.

Fig. 1. Project centralization example.

(1)
C. Simple Algorithm and Its Limitations
The main issue of project centralization is to properly
separate the class versions for each project. This entails
renaming the conflict classes and all their references toseparate their versions. However, such renaming may cause
shared classes not to be shareable anymore, as their internalreferences to other classes are renamed differently acrossprojects. Consider the example in Fig. 1 before centralization.
Project1 and Project2 can share class B before project
centralization. They have to rename their class C to adifferent name to resolve version conflict, though. After thatstep, B cannot be shared anymore as it references C.
Therefore, it is necessary to rename the conflict classes andpropagate their renaming effect in each project.
Given a project set of n size, our simple algorithm [4]renames all the conflict classes of the first n -1 projects andpropagates the renaming effect by traversing classdependency relations of each project. It does not distinguishbetween a conflict class and a class that is both shared and

Let P be a set of projects. To perform project centralization
correctly, we classify the classes of a project p P into thefollowing categories: Unique class. A unique class of a project p P has aunique name in p, which does not occur in the otherprojects.
 Conflict class. The name of a conflict class in p P also
exists in another project pP but with a different
implementation.
 Shared class. A shared class of p shares both its name andimplementation with some class in another project.
Consider the general scenario of centralizing projects froma project set P. There may exist multiple solutions that satisfy
Definition 3. If no conflict classes exist in any project of P,
the project centralization can directly take the union of all
projects in P as the centralized result. If some project in P
contains a conflict class, it needs to be separated while trying
196

Lecture Notes on Software Engineering, Vol. 2, No. 2, May 2014

conflict. It renames the class as long as it is a conflict classand the centralized result depends on the order of the projects.
For example, when centralizing projects Fig. 1 in the order ofProject2, Project1, and Project3, the simple algorithm cannot
share classes B and C in the centralized result. However, abetter solution after centralization is shown in Fig. 1, whereclasses B and C are both shared by Project2 and Project3.

Fig. 2. P-graph representation of a project set.

dependency relation in both P1, P2, but not in P3.
Pr.
1
2
3
4
5
6
7
8
9
10
Pr.
1
2
3
4
5
6

D. Graph Based Approach
In this section, we summarize our optimized project
centralization solution [4] based on a graph representation for
all projects. We define the P-graph representation for a
project set and discuss the optimized project centralization
algorithm. In the rest of this section, we fix P as an arbitrary
project set for centralization.
For a class name cln in P, we use a partition of projects torepresent the version relations of classes that share that name.
A project partition of cln is a set of projects such that two
projects occur in the same subset of the partition if they sharethe same version of the class named cln.
Definition 5. Let cln be a class name in P. A partition
structure of cln is the pair of cln and a partition of cln. Let PS
be a partition structure, we denote its name and partition by
PS.name and PS.partition, respectively.
Definition 6. A P-graph <N, E> of P consists a set ofpartition structures as a set of nodes, and an edge set E torepresent the dependency of these constraint structures,
which satisfies: 1) For each class name cln in P, there exists
exactly one partition structure node nN with n.name = cln. 2)
For two nodes m, n N, the existence of an edge e from m ton, denoted by (m, n), entails that the classes named m.name
and n.name have a dependency relation in some project pP,
and p occurs in both Pm.name and Pn.name. Each edge e
E is associated with a set of projects, denoted by e.set, thatsatisfy such a condition.
Let G=<N, E> be a P-graph. Each node n N is a partition
structure <n.name, n.partition> that represents all the version
relations of the class named n.name in P. For each edge e E,
its set e.set contains at least one project.
Fig. 2 shows the corresponding initialized P-graphs ofproject set in Fig. 1. The larger node is the partition structurenode, in which its name and partition of the class are shown.
For example, the node named A with its partition indicatesthat its name A exists in three projects P1, P2, and P3. They all
occur in the same subset, meaning that all these projects havethe same version of class named A. The label of an edge in a
P-graph shows those projects, in which two partition
structure nodes connected by that edge have a dependency
relation. For example, the edge from node B to Main
indicates that the classes named B and Main have a
197

7
8
9
10
Pr.
1
2
3
4
5
6
7
8
9
10

TABLE I: OVERVIEW OF ARGOUML PRODUCT VARIANTS
DrJavaLOC
Size (KB)#ClassRelease 20130901-r5756
89793
11895
3936
Release 20120818-r5686
89786
11895
3925
Release 20110822-r5448
89736
11886
3925
Release 20100913-r5387
88401
11659
3877
Release 20100816-r5366
88275
11655
3877
Release 20100711-r5314
87556
11572
3837
Release 20100507-r5246
87258
11499
3824
Release 20100415-r5220
85622
11506
3792
Release 20090821-r5004
81239
9798
3251
Release 20090803-r4975
81044
9711
3242
ArgoUML
LOC
Size (KB)#ClassAll optional feature enabled
1203485147
1915
All optional feature disabled
82924
3669
1494
Only Logging disabled
1181905018
1915
Only Cognitive disabled
1042094431
1678
Only Sequence Diagram
1149695033
1881
disabled
Only Use Case Diagram
1176365032
1874
disabled
Only Deployment Diagram
1172015024
1882
disabled
Only Collaboration Diagram 118769
5086
1896
disabled
Only state Diagram disabled 116431
5008
1880
Only Activity Diagram
1180665036
1897
disabled
HealthWatcher
LOC
Size (KB)#ClassBase–no extensions applied
5228
261
90
Command pattern applied
5646
273
94
State pattern applied
6112
302
106
Observer pattern applied
6222
309
108
Adapter pattern applied
6379
314
110
Abstract Factory pattern
6417
318
114
applied V1
Adapter pattern applied
6441
319
118
Abstract Factory pattern
6468
321
122
applied V2
Evolution–new functionality
7709
389
134
added
Exception Handling applied
7591
389
137

Correct project centralization requires separating theversion space of each project by renaming. Renaming a classalso entails renaming all references to it accordingly. We use
conflict edges to capture the effect that different versions of aclass are not separate due to the version separation of anotherclass that this class depends on.
Definition 7. Let G=<N, E> be a P-graph of P and e E be
an edge, where e = (m, n) with m, n N. The edge e is a
conflict edge if there exists two projects p1, p2  e.set so that
p1 and p2 occur in the same subset in n.partition but not inm.partition.
A conflict edge captures cases where classes must be
renamed to separate their version space. This ensures thatproject centralization preserves the behavior of each project.
For example, the dashed edge in Fig. 2 is a conflict edge
because P1 and P2 exist in the same subset of B.partition but
not in C.partition. Let e = (m, n) be a conflict edge with m, n
N. The conflict can be resolved by refining n.partition.
After a conflict is resolved, it may introduce more conflictedges. A correct separation of the version space of eachproject ensures that no unresolved conflicts remain.
Our optimized algorithm [4] adopts the P-graphrepresentation for projects. It takes a project set as input andoutputs a centralized project that satisfies Def. 3. The

Lecture Notes on Software Engineering, Vol. 2, No. 2, May 2014

algorithm first initializes the P-graph of P by collecting classnames, creates a constraint structure node for each of them,and adds their corresponding dependency edges. Then, theconflict edges are resolved in a topological order of the
P-graph by refining partitions. The algorithm iteratively
resolves all these conflict edges. For example, Fig. 2 gives aresolved P-graph result with no conflict edges. After
resolving all conflict edges, the last step performs normal
renaming substitution according to the obtained P-graph sothat two projects that occur in the same subsets of a partition
share that class. After performing such a normal substitution
according to Fig. 2, we can obtain the same project
centralization results in Fig. 1.

B. Case Studies and Results
The overview of product variants in our case studies issummarized in Table I, which contains both version variants
and product variants from a SPL. Column one lists the
product number and column two gives brief descriptions of
product variants for each software system by enabling anddisabling some features. Column three shows the lines ofsource code (without comments and whitespaces) for eachproduct. Column four and five list the product size andnumber of classes (*.class files), respectively.
DrJava [15] in our first case study is a lightweightdevelopment environment for writing Java programs. We use
its most recent ten version variants released in the last four
years. In the second and third case studies, we use the productvariants generated from existing software product line
ArgoUML-SPL [16], [17] and Health-Watcher [18], [19],respectively. ArgoUML-SPL is the software product line for
the UML modeling tool ArgoUML, and HealthWatcher is a
cloud computing application that manages health records andcomplaints.
Experimental results, where project centralization
algorithms are applied to all the selected products of asoftware project, are summarized in Table II. For each input
project set, we give its total number of classes (*.class files),storage usage, and average dependency in columns three,four and five, respectively. We compare the simple algorithm
and optimized algorithm in the number output classes, S.F.,
storage saving ratio, and algorithm execution time and total
time. We show these results in columns OUTPUT #Class,
S.F., Storage, Alg.Time and Total Time, respectively.
According to the input metrics, DrJava and ArgoUML areboth large-size projects, and HealthWatcher is smaller.
Although the number of input classes for DrJava is twice aslarge as in ArgoUML, the average dependency for classes in
DrJava is much larger.
In all experimental settings, the optimized algorithm
performs better by outputting fewer classes, sharing morecommon code and saving more storage. Compared with thesimple algorithm, the optimized algorithm shares 21.9%,
22.9% , and 35.2% more classes as indicated by the column
S.F. The optimized algorithm also saves 22.0%, 12.9% and29.2% more storage indicated by column Storage. However,
the algorithm execution time and total time of the simple
algorithm is faster. As the optimized algorithm needs toresolve conflict edges iteratively in the P-graph, theexecution time strongly depends on the average dependency
between input project sets. Its execution time becomes slow
when the number of input classes and average dependency inthe input project set are large, like for DrJava. From thesecase studies, we find that our optimized project centralization
solution is efficient enough to handle large project sets, andeffective in sharing common code and saving storage. The
centralized project preserves the behavior of all original
projects, which can be directly analyzed and verified toreveal defect of original projects.

III. EMPIRICAL STUDY
In this section, we present the case studies we haveconducted to investigate the feasibility of managing productvariants by project centralization. We have implemented the
project centralization solutions in a tool that performs
bytecode transformation using the ASM bytecode library[14]. It takes a project set as input and outputs the centralized
projects. In the rest of this section, we first define theevaluation criteria for measurement. Then, we explain ourcase studies and discuss the results in detail.
A. Evaluation Criteria
We identify three criteria to evaluate the effectiveness insharing code and the run time of a centralization algorithm.
Criterion 1. Effectiveness of sharing common code isdefined as Sharing Factor (S.F.), which is the ratio of, sharedclasses to output classes:
S.F. =# ClassShared#OutputClass(2)

A class in the output is counted as shared if at least two
projects share it after centralization. Consider the project
centralization results in Fig. 1. Classes A, B, C are shared bymultiple projects in the output classes, but classes Unique andMain are not. S.F. ranges from 0 to 1; the larger its value, themore classes are shared. The trivial renaming approachrenames all classes of each project and shares no classes; itsvalue of S.F. is therefore 0.
Criterion 2. The effectiveness of saving storage is definedas the ratio of storage usage after centralization to the one
before centralization.
This measure shows the storage that can be saved byproject centralization. It also indicates the possible runtime
memory that can be saved when simulating an application byprocess centralization [4], where a class is only necessary to
be loaded to the JVM once by centralization.
Criterion 3. Performance is the execution time of project
centralization algorithm and total time that includes
additional time to write transformed results to disk, but notincluding the prepossessing and initializing time to build
internal data structure from class files from disk.
All experiments were measured on an Intel Core i7 Mac
2.4 GHz with 8 GB of RAM, running MAC OSX 10.8.3 andOracle’s Java VM, version 1.7.0 21.

C. Threat to Validity
The main threat to our work is that we only performed casestudies on three open source projects and selected ten
variants for each project. However, the selected projects are198

Lecture Notes on Software Engineering, Vol. 2, No. 2, May 2014

are slightly different. This threat can be diminished byapplying the same methodology of project centralization to afiner level such as the method and attribute levels. We leavesuch a refinement as future work.

real-world non-trivial projects and have been also be used incase studies by many other researchers. Another threat is that
our approach makes project centralization on the file level
without merging class files. It cannot share the classes that
Project

Algorithm

DrJavaSimpleTABLE II: EXPERIMENTAL RESULTS OF PROJECT CENTRALIZATIONINPUTOUTPUT
S.F. (%)
Storage#Class(%)#ClassSize (KB)
A.D.
37486

11307617199

Optimized
ArgoUML

Simple

18312

48484

3121

Optimized
HealthWatcher

Simple

1133

3195

373

Optimized

Alg. Time(ms)

Total Time
(ms)

29194

6.7

82.2

6920

10949

22247

28.6

60.2

37166

40063

6399

27.7

43.0

2273

3286

4485

50.6

30.1

6959

7706

771

10.9

82.1

1128

1242

448

46.1

53.8

1513

1585

effectiveness with the current approaches in sharing common
code of multiple product variants.

IV. RELATED WORK
Hnetynka et al. [20] originally discussed the version
conflict problem in component-based systems written in Java.
They adopt the renaming approach by augmenting the classname of each variant with a version identifier during dynamic
class loading, which does not share common code.
Managing the product variants by revision control tools iscommonly used in practice. A difficult issue is to represent
multiple simultaneous changes of a single product. Software
merging is a widely used technique similar to project
centralization, which merges multiple product variants into
single one. However, Mens [8] points out that current
software merging techniques give no guarantees about the
behavior of merged code. On the other hand, project
centralization preserves the behavior of each project so that
program analysis techniques can be directly applied to thecentralized project as shown in our previous work [4].
Managing product variants to refactor them into a SPL isanother technique related to project centralization [11].
However, such techniques require manual analysis based onrequirement to identify features and establish traces between
features and their location in the code. Existing approaches
are mostly work on the model level [2], [11], [7]. Our project
centralization focuses on sharing common code of existingproducts to reduce maintenance cost and remove version
conflicts for program analysis.

V. CONCLUSION AND FUTURE WORKIn this paper, we explore the usefulness of project
centralization for managing similar product variants. We firstpresent the basic concepts and definitions of project
centralization. Then, we discuss a simple solution and an
optimized one. We conduct empirical evaluations of ourapproaches on three real-world large software systems. The
result demonstrates the effectiveness of our technique inmanaging similar product variant by avoiding redundant
code. Based on this exploratory work, our future work willrefine project centralization to method level and compare its
199

REFERENCES
M. M. Lehman and J. F. Ramil, “Software evolution in the age ofcomponent-based software engineering,” in Proc. IEE Softw., vol. 147,
Dec. 2000, pp. 249–255.
[2] J. Rubin, K. Czarnecki, and M. Chechik, “Managing cloned variants: aframework and experience,” in Proc. 17th Int. Softw. Product Line
Conf., 2013, pp. 101–110.
[3] R. Santelices, P. K. Chittimalli, T. Apiwattanapong, A. Orso, and M. J.
Harrold, “Test-suite augmentation for evolving software,” in Proc.
23rd IEEE/ACM Int. Conf. on Autom. Softw. Eng., 2008, pp. 218–227.
[4] L. Ma, C. Artho, and H. Sato, “Improving automatic centralization byversion separation,” IPSJ Trans. on Programming, 2013.
[5] D. Faust and C. Verhoef, “Software product line migration anddeployment,” J. of Softw. Practice and Experience, vol. 33, pp.
933–955, 2003.
[6] T. Mende, R. Koschke, and F. Beckwermert, “An evaluation of code
similarity identification for the grow-and-prune model,” J. Softw.
Maint. Evol., vol. 21, no. 2, pp. 143–169, 2009.
[7] S. She, R. Lotufo, T. Berger, A. Wasowski, and K. Czarnecki, “Reverse
engineering feature models,” in Proc. 33rd Int. Conf. on Softw. Eng.,
2011, pp. 461–470.
[8] T. Mens, “A state-of-the-art survey on software merging,” IEEE Trans.
Softw. Eng., no. 5, pp. 449–462, 2002.
[9] S. Apel, O. Lessenich, and C. Lengauer, “Structured merge with
auto-tuning: balancing precision and performance,” in Proc. 27th
IEEE/ACM Int. Conf. on Autom. Softw. Eng., 2012, pp. 120–129.
[10] S. Apel, J. Liebig, B. Brandl, C. Lengauer, and C. Kästner,“Semistructured merge: rethinking merge in revision control systems,”
in Proc. 19th ACM SIGSOFT symp. and the 13th Euro. Conf. on
Foundations of Softw. Eng., 2011, pp. 190–200.
[11] J. Rubin and M. Chechik, “A framework for managing cloned productvariants,” in Proc. 35th 2013 Int. Conf. on Softw. Eng., 2013, pp.
1233–1236.
[12] W. Visser, K. Havelund, G. P. Brat, S. Park, and F. Lerda, “Model
Checking Programs,” Autom. Softw. Eng., vol. 10, pp. 203–232, 2003.
[13] C. K. Roy, J. R. Cordy, and R. Koschke, “Comparison and evaluationof code clone detection techniques and tools: A qualitative approach,”Sci. Comput. Program., vol. 74, pp. 470–495, 2009.
[14] E. Bruneton, R. Lenglet, and T. Coupaye, “ASM: A code manipulation
tool to implement adaptable systems,” Adaptable and Extensible
Component Systems, 2002[15] DrJava Project. [Online]. Available: http://www.drjava.org/[16] M. V. Couto, M. T. Valente, and E. Figueiredo, “Extracting software
product lines: a case study using conditional compilation,” in Proc.
15th Euro. Conf. on Softw. Maint. and Reeng., 2011, pp. 191–200.
[17] ArgoUML-SPL.
(Sep.
16,
2013).
[Online].
Available:
http://argouml-spl.tigris.org/[18] E. Cavalcante, A. Almeida, T. Batista, N. Cacho, F. Lopes, F. C.
Delicato, T. Sena, and P. F. Pires, “Exploiting software product lines to[1]

Lecture Notes on Software Engineering, Vol. 2, No. 2, May 2014
develop cloud computing applications,” in Proc. 16th Int. Softw.
Product Line Conf., vol. 2, 2012, pp. 179–187.
[19] Health Wactcher. (Sep. 19, 2013). [Online]. Available:
http://www.comp.lancs.ac.uk/~greenwop/tao/java.htm[20] P. Hnetynka and P. Tuma, “Fighting class name clashes in Javacomponent systems,” Modular Programming Languages, vol. 2789, pp.
106–109, 2003.

Cyrille Artho is a senior researcher at AIST, Japan. In
his Master's thesis, he compared different approaches
for finding faults in multi-threaded programs. Later in
his Ph.D. thesis, he continued his search for such
defects, earning his Doctorate at ETH Zurich in 2005.
After graduation he worked at NII, Tokyo, for two
years, and then moved to AIST.

Lei Ma is a Ph.D. candidate at Department of ElectricalEngineering, the University of Tokyo. He received his
B.S. from Shanghai Jiao Tong University in the
Department of Computer Science in 2009, and M.S.
from the University of Tokyo in Department ofElectrical Engineering and Information System. Hisinterests cover various topics related to programming
languages, type system, and software management.

Hiroyuki Sato is an associate professor in the
University of Tokyo. He received his B.Sc., M.Sc. and
Ph.D. from the University Tokyo in 1985, 1987, 1990,
respectively. He is majoring in Computer Science andInformation Security.

200