Software Ingredients: Detection of Third-party Component
Reuse in Java Software ReleaseTakashi Ishio

Raula Gaikovina Kula

Tetsuya Kanda

ishio@ist.osaka-u.ac.jp

raula-k@ist.osaka-u.ac.jp

t-kanda@ist.osakau.ac.jp

Osaka University
Osaka, Japan

Osaka University
Osaka, Japan

Daniel M. German

Osaka University
Osaka, Japan

Katsuro Inoue

University of Victoria
Victoria, BC, Canada

Osaka University
Osaka, Japan

dmg@uvic.ca

inoue@ist.osaka-u.ac.jp

ABSTRACTA software product is often dependent on a large numberof third-party components. To assess potential risks, suchas security vulnerabilities and license violations, a list ofcomponents and their versions in a product is important for
release engineers and security analysts. Since such a list is
not always available, a code comparison technique named
Software Bertillonage has been proposed to test whether aproduct likely includes a copy of a particular component
or not. Although the technique can extract candidates ofreused components, a user still has to manually identify theoriginal components among the candidates. In this paper,
we propose a method to automatically select the most likely
origin of components reused in a product, based on an assumption that a product tends to include an entire copy ofa component rather than a partial copy. More concretely,
given a Java product and a repository of jar ﬁles of existing components, our method selects jar ﬁles that can provide
Java classes to the product in a greedy manner. To compare
the method with the existing technique, we have conducted
an evaluation using randomly created jar ﬁles including up
to 1,000 components. The Software Bertillonage technique
reports many candidates; the precision and recall are 0.357
and 0.993, respectively. Our method reports a list of originalcomponents whose precision and recall are 0.998 and 0.997.

Keywords
Software reuse, reverse engineering, origin analysis

1. INTRODUCTION
Software reuse is crucial for eﬃcient software development. A software project uses components developed outside of the project, subsequently produces software that is a
Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor proﬁt or commercial advantage and that copies bear this notice and the full citation on the ﬁrst page. Copyrights for components of this work owned by others thanACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior speciﬁc permission
and/or a fee. Request permissions from permissions@acm.org.

MSR’16, May 14-15, 2016, Austin, TX, USA
c 2016 ACM. ISBN 978-1-4503-4186-8/16/05. . . $15.00

DOI: http://dx.doi.org/10.1145/2901739.2901773

potentially reusable component in other projects. Software
reuse activity is now commonplace in both open source software community and industry. Heinemann et al. [19] reported that black-box reuse is common among open sourceJava projects. Bavota et al. [5] reported that although thetrend of growing projects in the Apache ecosystem is linear, the growth of component dependencies are exponential.
Rubin et al. [37] reported that industrial developers extract
reusable components from existing software products to develop core assets for their new products. Mohagheghi et al.
[29] reported that reused components are more reliable than
non-reused code.
Reusing a component may increase a potential risk of vulnerabilities and license violations caused by the component
and its transitively dependent components. For example,
the Google Web Toolkit (GWT) project [18] includes various
components in its release so that it can be used without installation of other components. A single jar ﬁle gwt-dev.jar
in GWT 2.7.0 includes class ﬁles reused from three vulnerable components: Apache Xalan 2.7.1, HttpClient 4.3.1, andCommons-Collections 3.2.1. The vulnerabilities have a risk
to allow remote attackers to access external resources [32],perform man-in-the-middle attack [33], and execute arbitrary code [2]. It is hard for users to identify such a potential
risk, because internal components are not directly visible tothem. Sonatype reported that many applications include
severe or critical ﬂaws inherited from their components [7].
In order to assess a potential risk of components, releaseengineers and user-side security analysts need a complete
list of components that are actually included in a productrelease. However, such a list is not always available to themoutside of a development team. In the case of gwt-dev.jar,
its build ﬁle (build.xml) must be analyzed to identify its
internal components. The dependencies are unavailable on
the Maven Central Repository, because the jar ﬁle can bereused without the dependent components.
To address the problem, an existing technique named Software Bertillonage [8, 9] has been proposed to analyze a jar
ﬁle. A simple MD5 ﬁle hash comparison is unable to identify
a reused class ﬁle, because it cannot compare class ﬁles generated by diﬀerent compilers. Davies et al. [9] reported that
48% of jar ﬁles in Debian GNU/Linux packages have no classﬁles that were identical to any class ﬁles in the Maven Central Repository. Instead of a ﬁle hash, Software Bertillonage

introduced a class signature to compare two classes ignoring their details. The approach enables to identify common
classes between two jar ﬁles. By comparing a product jar ﬁlewith each of existing components, the technique can identify
components whose classes are entirely/partially included ina product. However, common classes between jar ﬁles does
not imply code reuse between the ﬁles. For example, if a
product includes an entire copy of Apache Commons components, then the Software Bertillonage tool reports that the
product includes the components and also includes a partial
copy of GWT, because GWT includes the same classes. A
user still has to manually identify the original components
among the reported candidates.
In this paper, we propose a method to automatically selecta set of jar ﬁles that is the most likely origin of components
reused in a product. We identify existing components thatcover the contents of a target jar ﬁle as much as possible
in a greedy manner, assuming a product tends to include
an entire copy of a component rather than a partial copy.
The assumption is based on an observation that most ofdevelopers copy a jar ﬁle as a black box [16, 19]. All theclasses in the components can be automatically repackaged
into a single runnable jar ﬁle using existing tools such as
Eclipse Runnable Jar File Exporter [13] and Apache Maven
Assembly Plugin [3].
We conducted an experiment to evaluate our approachagainst Software Bertillionage, evaluating the ability to accurately identify original components reused in a target jar
ﬁle. The experiment used artiﬁcially created jar ﬁles using a dataset named sourcerer-maven-aug12, which is asnapshot of the Maven Central Repository. We randomly
selected up to 1,000 jar ﬁles in the dataset, put the contents
into a single jar ﬁle, and then detected the original jar ﬁles.
The precision and recall of Software Bertillonage are 0.357
and 0.993, respectively. Our method achieved much better
results, with an improved precision and recall of 0.998 and
0.997 for the dataset. The result shows that our method
successfully identiﬁes the original components included in a
product.
We use two cases to highlight practical usefulness and implications. We applied our method to actual jar ﬁles of Facebook LinkBench and muCommander 0.9.0. The ﬁrst caserepresents a release engineering situation that compares thedependencies managed by developers with components actually included in a product. The second case assesses a risk ofa product whose components are unrecorded by developers.
The contributions of the paper are summarized as follows.
• We deﬁne a method to detect multiple third-party components in a jar ﬁle. Our method is eﬃcient and detects many components.
• Our experiment shows the accuracy of our approachcompared with Software Bertillonage. The accuracyof the previous work has not been evaluated in [8, 9].
The evaluation is conducted using actual components
available in a public dataset.
• We reported the result of analysis on actual software
binaries. It shows the usefulness of our method.
Section 2 shows related work of our approach. The approach itself is detailed in Section 3. Section 4 presents theevaluation of our approach using a dataset constructed from
the Maven repository. Section 5 presents the analysis ofactual binaries. Section 6 describes the threats to validity.
Section 7 describes the conclusion and future work.

2.

RELATED WORK

We have categorized related work into three groups: Analysis of reuse activity, detection of software reuse, and support of software reuse. Our research is included in detectionof software reuse.

2.1

Analysis of Reuse Activity

Heinemann et al. [19] analyzed code reuse in open sourceJava projects. They identiﬁed black-box reuse using a corpus of 20 popular libraries; they extracted references to library classes in a target program as an instance of reuse.
Our method also uses a corpus of existing components, but
our method identiﬁes classes copied to a target program.
Bavota et al. [5] reported that the number of inter-project
dependencies grows exponentially. The dataset is extracted
from conﬁguration ﬁles for build tools such as Maven. While
the approach is likely precise in most cases, dependencies
declared in a conﬁguration ﬁle may be diﬀerent from actual
dependencies, as developers can keep a copy of source andbinary ﬁles in their project.
Teyton et al. [41] analyzed library migrations using a listof packages for each library. The list associates a package
name to a library name. Although the list-based detection isreasonable, it is not applicable to identify a version number.
Code clone detection has been used to analyze sourcecode reuse between projects. Kamiya et al. [23] proposed
CCFinder to detect similar code fragments between ﬁles.
German et al. [17] used CCFinder to detect code siblings
reused across projects. They identify the original project ofa code sibling by investigating the source code repositories ofthe projects. Hemel et al. [21] analyzed vendor-speciﬁc versions of Linux kernel using their own clone detection tool.
The analysis shows that each vendor created a variant ofLinux kernel and customized many ﬁles in the variant.

2.2

Detection of Software Reuse

Davies et al. [8, 9] proposed Software Bertillonage to identify the origin of a jar ﬁle using classes and their methods inthe ﬁle. The method compares the contents of a jar ﬁle witheach of jar ﬁles in a repository, and then reports the mostsimilar one as the original. It enables to recover a full nameof a jar ﬁle (e.g. junit-3.8.1.jar) from a shortened name(e.g. junit.jar). The method also deﬁnes metrics representing the degree of inclusion relationship between two jar
ﬁles so that a user can test whether a jar ﬁle includes a partof another jar ﬁle or not. German et al. [16] demonstrated
the approach can detect OSS jar ﬁles included in proprietary
applications. Mojica et al. [30] used the same approach toanalyze code reuse among Android applications.
Di Penta et al. [10] used class names to identify software
license for a jar ﬁle, instead of a component name. Since a
jar ﬁle may be distributed without documents of software
license, the method extracts class names as keywords forsearch engines. The method can recover software license if
the classes are included in a well-known library available on
the Internet.
Sæbjørnsen et al. [38] proposed a clone detection for binary code. Qiu et al. [35] proposed a code comparison
method for a binary form to identify library functions included in an executable ﬁle. These techniques are applicableto detect functions copied from library code in a target program, by comparing all the versions of components with thetarget program. Our method detects reuse in a componentlevel rather than a function level.
Hemel et al. [20] proposed a binary code clone detection to
identify code reuse violating software license of a component.
The method compares the contents of binary ﬁles between
a target program and each of existing components. The
framework is the same as Software Bertillonage; it enables
a user to test whether a component is likely included in atarget program or not. While reused code fragments aredetected as code clones, code clones are not always reuse.
For example, if a target program A uses a library B thatis also used in another library C, the method reports twocode clones between A-B and between A-C. A user has tomanually investigate clones to determine whether they are
actual reuse or not.
Kawamitsu et al. [25] proposed a technique to identify
an original version of source code in a library’s source code
repository. To analyze a program, a user of the techniquemust know what library is included in the program. Our
technique automatically extracts the information from a target program.
Steidl et al. [40] proposed to detect source code move,
copy, and merge in a source code repository. The approachcompares the full contents of ﬁles, while our approach intentionally ignore details of binary ﬁles.
Kanda et al. [24] proposed a method to recover an evolution history of a product and its variants from their sourcecode archives without a version control. The approach also
compares the full contents of source ﬁles, using a heuristicthat developers tend to enhance a derived version and do
not often remove code from the derived version.
Chen et al. [6] proposed a technique to detect clones ofAndroid applications. The analysis computes similarity between control-ﬂow graphs of methods, and recognize an Android application as a clone of another application if the two
applications have a large number of similar methods. To
compare application-speciﬁc code separately from existing
libraries, the technique uses a white-list including package
names of popular libraries.
Luo et al. [28] proposed a code plagiarism detection applicable to obfuscated code. The detection method identiﬁes
semantically equivalent basic blocks in two functions. Our
approach assumes that developers own their code and thecode of a target program is not obfuscated.
Sojer et al. [39] pointed out that ad-hoc reuse from theInternet has a risk of a license violation. Inoue et al. [22]proposed a tool named Ichi-tracker to identify the origin of
ad-hoc reuse. It searches clones of a source ﬁle across various
repositories on the Internet and visualizes the similarities.
Our method focuses on clone-and-own reuse of components
rather than ad-hoc reuse.

2.3 Support of Software Reuse
Detected instances of source code reuse can be seen as
clues to extract the common functionalities in software products. Bauer et al. [4] proposed to extract code clones acrossproducts as a candidate of a new library. Duszynski [12] proposed a code comparison tool to analyze source code commonalities from multiple similar product variants. Fischer
et al. [15] proposed to extract common components fromexisting product variants and compose a new product.

Thung et al. [42] proposed a method to recommend libraries that are likely useful to developers, using item-set
mining for libraries. The approach also uses the Maven
repository as a source of libraries. Components detected byour method can be used as input for the recommendation
system.
Dietrich et al. [11] analyzed binary compatibility between
versions of a library. As similar to [16], the analysis used abinary-level content comparison to identify the origin of alibrary jar ﬁle. The analysis focused on libraries used by aprogram via method calls, rather than libraries whose copies
are included in the program.
Raemaeker et al. [36] analyzed the relationship between
version numbers and binary compatibility of a library. The
analysis compares identiﬁers between versions and showsthat identiﬁers in an old version are often unavailable ina new version. The observation implies that comparison ofclasses and methods is eﬀective to identify a version of acomponent.
Kula et al. [26] proposed a visualization to investigate
a history of component update in a project. Developers
can identify outdated components in their project, using
the history and statistics of dependencies extracted from
the Maven repository. While the visualization extracts dependencies of a target project from a conﬁguration ﬁle for
Maven (pom.xml), our method can provide supplementary
dependencies unrecorded in the ﬁle.
Yano et al. [43] proposed a visualization to investigate apopular combination of library versions. For example, givena pair Apache Commons HttpClient and Collections, thevisualization shows the most popular combination is HttpClient 3.1 and Collections 3.2.1. Since such a popular combination works properly, developers can reduce a risk of version incompatibility. This visualization is also dependent
on dependencies recorded in pom.xml ﬁles. Our method canprovide dependencies in actual software releases for the visualization.

3.

COMPONENT DETECTION

Our method detects components that are the most likely
reused in a target product jar ﬁle. The method assumes all
existing versions of components are accessible from a hosting repository. The hosting repository is a collection of jar
ﬁles. A jar ﬁle should at least contain one class to be considered a component. The Maven Central Repository is awell-known component hosting repository; it has been usedin [8, 9]. Similarily, we employ a snapshot of the MavenCentral Repository named sourcerer-maven-aug12, that isa part of UCI Source Code Data Sets [27].
Our method takes as input a target jar ﬁle t and a setof jar ﬁles R in the repository. Our method selects jar ﬁlesfrom the repository such that each jar ﬁle provides class ﬁles
to t. Since a simple list of jar ﬁle names is not informative
for users to analyze actual reuse, we represent reused jar
ﬁles in t as a list of pairs (Ji , Ci ); Ji is a set of jar ﬁlesincluding a set of classes Ci in the target t. Multiple jar ﬁles
are detected as the origin of reused code if they have thesame classes Ci .
Our method comprises two steps: Signature extraction
and signature-based comparison. To identify class ﬁles common to t and jar ﬁles in R, we use a class signature representing the contents of a single class. Hence, the ﬁrst step
constructs a database of signatures for each jar ﬁle in the'

 



      

  

     

   


 

 !" #" $
 %" &$

Figure 1:
method

 


 


An example input and output of ourrepository R. The second step is a greedy algorithm that
repeatedly identiﬁes the largest jar ﬁle that covers the contents of t as much as possible using the database. Comparedwith Software Bertillonage, our method newly introduces anextension of class signature and the greedy algorithm.
Figure 1 illustrates an example input and output of our
method. Given the target.jar ﬁle, our method compares
the contents with jar ﬁles in the repository. Our method
reports that X-1.0.jar is the origin of three classes A, B,
and C, and Z-0.2.0.jar is the origin of two classes E andF, because the target jar includes all the classes in them.
Although the class E can be seen as a copy from Y-0.1.jar,
our method selects only Z-0.2.0.jar because it covers moreclasses.
Software Bertillonage does not provide such an automatic
analysis. That method deﬁnes a similarity metric between
jar ﬁles t and r, using a class signature to compare classes,
as follows.
sim(t, r) =|Classes(t) ∩ Classes(r)||Classes(t) ∪ Classes(r)|In the case of Figure 1, we can get the similarity metricvalues as follows: sim(t, X-1.0) = 0.500, sim(t, X-1.1) =0.429, sim(t, Y-0.1.1) = 0.167, and sim(t, Z-1.0) = 0.333.
Since X-1.0 is more similar to t than X-1.1, X-1.0 is more
likely a code origin of t than X-1.1. While X-1.1 can beremoved from the candidates, the similarity metric does
not show the relationship among the remaining candidates.
Hence, a user has to manually analyze the contents of three
jar ﬁles to identify the origin of classes.

3.1 Signature Extraction
The ﬁrst step of our method translates a class ﬁle into a
signature for comparison. If a signature of a class c1 is thesame as one of another class c2 , we regard the classes as thesame element when comparing a set of classes between jar

ﬁles.
A simple ﬁle hash such as MD5 and SHA-1 is inapplicable,
because generated class content can vary and is dependent
on compiler and conﬁguration settings such as JDK version
number and inclusion of debug information.
A signature of a class c is a set of the following attributes.
• Class name of c. It is an empty string if c is an anonymous class.
• Name of the parent class of c.
• Name of the outer (enclosing) class of c if c is an innerclass.
• Interfaces implemented by c.
• Fields deﬁned in c. Each ﬁeld is represented by its
name and type. A declaration order is ignored.
• Methods deﬁned in c. Each method is represented
by the following attributes. A declaration order is ignored.
– Method name. Constructors and static initializers are represented by their internal names <init>and <clinit>, respectively.
– Modiﬁers, e.g. public, private, protected, andsynchronized.
– The types of arguments and return value.
– A set of method call instructions in the method.
We use only method names, receiver types, andargument types, ignoring their locations in themethod.
– A set of ﬁeld access instructions in the method.
We use only ﬁeld names, ﬁeld types, and ownerclasses of the ﬁelds, ignoring their locations in themethod.
A signature equals to another signature if and only if all their
attributes are the same. The deﬁnition of a class signature isan extended version of [8, 9]; method calls and ﬁeld access inmethods are added. We included the additional attributes
so that we can distinguish diﬀerent versions of a component
as much as possible.
While a class signature is deﬁned as a set of attributes,
our implementation extracts all the above attributes from aclass and concatenates them into a single string, and thentranslates it into a single SHA-1 hash value. Hence, comparison of two classes is implemented by comparison of two
hash values.
It should be noted that class names in a class signature
are fully qualiﬁed names including their package names. Although developers may clone source ﬁles from a library andmodify the package names, both our method and Software
Bertillonage do not analyze such a case.
A signature excludes subclasses and synthetic methods
and ﬁelds generated by compilers that are not included insource code. They are recognized by the synthetic accessmodiﬁer in bytecode and a character “$” in their names.
All the jar ﬁles in a repository R are translated into a
signature database. A signature database is represented bya simple hierarchical structure. The database contains a listof jar ﬁle names. Each jar ﬁle name is associated with a list

Algorithm 1 Component Detection
1: Initialize A = Classes(t)2: Classify jar ﬁles in R to groups and sort them by a descending order of overlapN : Rs = R1 , R2 , · · · .
3: for i = 1 to |Rs | do4:
while Ri = φ do
5:
Select (J, C) such thatJ ⊆ Ri ∧ ∀r ∈ J. A ∩ Classes(r) = C∧∀r ∈ Ri \ J. A ∩ Classes(r ) = C
∧ maxr∈Ri |A ∩ Classes(r)| = |C|6:
print (J, C) as a result if C = φ.
7:
Ri ← Ri \ J, A ← A \ C
8:
end while
9: end forof classes. Each class is represented by a pair of its nameand signature hash value.
A signature extraction process can analyze jar ﬁles andclasses in parallel, since jar ﬁles are independent of one another and a class signature is computed analyzing only one
class ﬁle at a time. We can incrementally analyze new jar
ﬁles in a component repository that grows day by day.

3.2 Signature-based Comparison
The second step of our method uses a database extracted
from a repository R to identify a subset of jar ﬁles in R thatcover classes in t. Algorithm 1 represents the entire processof this step. In the algorithm, Classes(x) denotes a set ofclasses in a jar ﬁle x.
The algorithm ﬁrstly extracts A, which is a set of classes
to be analyzed, from t. The process is the same as thesignature extraction step.
The line 2 in the algorithm determines an order of comparison of jar ﬁles in R. We use the overlap coeﬃcient between
class names in t and each r in R, deﬁned as follows.
overlapN (t, r) =|N ames(t) ∩ N ames(r)||N ames(r)|where N ames(x) is a set of class names in a jar ﬁle x.
We classify jar ﬁles in the repository into groups Rs =
R1 , R2 , · · · , so that the groups satisfy a descending orderof overlapN values as follows.
∀r, s ∈ Ri .

overlapN (t, r) = overlapN (t, s)∀r ∈ Ri , s ∈ Rj . i < j ⇐⇒ overlapN (t, r) > overlapN (t, s)
Each Ri is a subset of jar ﬁles in R. We exclude jar ﬁles
whose overlapN value is zero from the analysis. On theother hand, we use no threshold for ﬁltering. We analyze all
the jar ﬁles that share at least one class name with t.
The descending order of the overlapN metric enables us
to check an entirely copied jar ﬁle earlier than a partiallycopied jar ﬁle. If all the classes in r are copied to t, t must
include the class names (i.e. overlapN (t, r) = 1). We didames(t)∩N ames(r)|not use the Jaccard index |N, because a|N ames(t)∪N ames(r)|partially copied jar ﬁle may have a higher value.
The overlapN uses class names instead of class signatures.
When two jar ﬁles r1 and r2 are copied to t, the jar ﬁles haveoverlapN (t, r1 ) = overlapN (t, r2 ) = 1 even if they include
diﬀerent versions of the same classes.
The while loop in the lines 4 through 8 is the main part of
the algorithm. The line 5 compares a set of classes A with

jar ﬁles in Ri using class signature, and then select jar ﬁles J
providing the largest intersection C. The selected pair (J, C)
is reported to a user at the line 6. The line 7 removes theselected classes C from A to ensure that the classes have theonly one code origin. The loop continues until all the jar ﬁlesin Ri are analyzed. If no jar ﬁles in Ri have a non-empty
intersection with A, a pair (J = Ri , C = φ) is extracted.
The pair makes Ri empty and terminates the while loop.
And then, the analysis moves to the next jar ﬁle set Ri+1 .
The algorithm terminates after all the jar ﬁle sets have been
analyzed.
Let us illustrate how the algorithm works on the example
repository shown in Figure 1. The repository includes four
jar ﬁles as follows.
Classes(X-1.0) =Classes(X-1.1) ={A, B, C}{A, C, D}Classes(Y-0.1.1) ={E}

Classes(Z-0.2.0) ={E, F}

Our algorithm ﬁrstly computes overlapN values. Since thetarget jar ﬁle includes three classes A, B, and C, the overlap
value overlapN (t, X-1.0) = 1. The target jar ﬁle also includes all the class names in Y-0.1.1 and Z-0.2.0. Hence,
the repository is split into two sets: R1 = {X-1.0, Y-0.1.1,
Z-0.2.0} and R2 = {X-1.1}. If Z-0.2.0 included anotherversion of class C, R1 still includes the jar ﬁle because theoverlapN value does not change. The overlapN value represents a situation that the jar ﬁle could be an entire copy
but a class is accidentally overwitten by another version of
the class. If Z-0.2.0 included another class H instead of C,
the jar ﬁle moves to R2 because it is regarded as a partial
copy.
The while loop in the algorithm analyzes R1 as follows.
At the beginning, a set of analyzed classes A contains all theclasses in the target jar ﬁle: A = {A, B, C, E, F, G}. The largest
intersection with R1 is C = {A, B, C} in X-1.0. Hence, a pair({X-1.0}, {A, B, C}) is reported as a result. At the line 7, thejar ﬁle and classes are removed from R1 and A respectively;
i.e. R1 = {Y-0.1.1, Z-0.2.0}, A = {E, F, G}. The second
iteration of the loop outputs ({Z-0.2.0}, {E, F}) and resultsin R1 = {Y-0.1.1}, A = {G}. In the third iteration, A nolonger has an intersection with Y-0.1.1. The resultant pair({Y-0.1.1}, φ) is ignored at the line 6. R1 becomes empty,
and then the algorithm proceeds to R2 . Since X-1.1 has nointersection with A, it is also ignored. As a result, two pairsof jar ﬁles and classes are output by our method as follows.
J{ X-1.0.jar }{ Z-0.2.0.jar }C{ A, B, C }{ E, F }The result shows that three classes are copied from X-1.0
and two classes are copied from Z-0.2.0. The result also
implies the remaining class G is likely unique to the target
jar ﬁle, because it is not found in any jar ﬁles in R.
The computational cost of the comparison step is dependent on both the size of a target jar ﬁle t and a repository
R. The worst case is O(nk), where n is the total numberof class ﬁles in R, k is the number of jar ﬁles reused in t,
respectively. Computation of overlapN values takes O(n)time, because it tests whether each class name in r ∈ R is
included in t or not, using a hash set of class names for t(O(1) time for each test). Similarly, computation of inter-section at the line 5 compares class signatures in O(n) timefor each iteration, using a hash set for class signatures. The
while loop is repeated k times until the k jar ﬁles in t are
identiﬁed. To reduce the cost, our implementation reuses
the already computed intersections in the loop; when A is
updated to A (A ← A \ C), updated intersections for A isobtained by A ∩ Classes(r) = (A ∩ Classes(r)) \ C.

4. EVALUATION
To evaluate our method, we try to answer the following
research questions:

Algorithm 2 Goldset Construction
1: Initialize t as an empty ﬁle.
2: for i = 1 to N do
3:
Randomly select a jar ﬁle ri ∈ R such that
N ames(ri )  1≤k≤i−1 N ames(rk ) and ri is a diﬀerent component from rk (1 ≤ k ≤ i − 1).
4:
Copy class ﬁles in ri to t. Skip a class ﬁle if the classis already included in t.
5: end for
6: Add t and G(t) = {r1 , · · · , rN } to the golden dataset.

RQ1. How accurate is the result reported by our method?

Research Design. For RQ1, we compare our methodwith Software Bertillionage. We use a golden dataset toevaluate precision and recall of the methods. To cover various combinations of existing components, we create our own
dataset. More concretely, we randomly select jar ﬁles in therepository and copy the contents to a new jar ﬁle. Then weapply the methods under comparison to the created jar ﬁleand compare the reported results with the original ﬁles.
For RQ2, we evaluate practicality since our method ismore computationally expensive. We use the performancedata collected from RQ1 in relation to time and hardware
considerations.

4.1 Comparison with Software Bartillonage
As the baseline of accuracy, we use the similarity metric ofSoftware Bertillonage to list candidates of jar ﬁles included
in a target jar ﬁle. If a jar ﬁle r ∈ R satisﬁes sim(t, r) > 0,r is selected as a candidate. If multiple versions of the same
component are involved in the list, we select only the mostsimilar version (if tied, select all of them) and exclude lesssimilar versions. In the case of Figure 1, the resultant listof candidates is D = {X-1.0}, {Y-0.1.1}, {Z-0.2.0}, asillustrated in Section 3. We refer to this similarity-based
list as a “Bertillonage” list. We do not use a threshold forﬁltering jar ﬁles so not to miss original ﬁles.
Our method added two elements to Software Bertillonage
approach: an extended class signature and a greedy algorithm. To analyze how the elements contribute to the result,
we introduce two variants of our method.
Bert+Sig is a list of jar ﬁles created in the same way as
the Bertillonage list but using our class signature.
Bert+Greedy is a result of our greedy algorithm but uses
a class signature deﬁned in [8, 9].
We refer to our method as “Full” to distinguish it from thetwo variants.

4.2 Dataset Construction
We create a jar ﬁle from jar ﬁles in a repository R. We
use a snapshot of the Maven Central Repository named
sourcerer-maven-aug12 as our repository R. The repository includes 172,232 jar ﬁles in the dataset, excluding sourcecode archives and corrupted ﬁles. The ﬁles include 23,336
artifact IDs in Maven.
To analyze how accuracy is aﬀected by the number of jar
ﬁles included in a target jar ﬁle, we introduce a parameter

150000#Classes in a jar

RQ2. Does our method ﬁnish the analysis in a practical
time?

10000050000
010−200210−400410−600

610−800 810−1000

N

Figure 2: Distribution of the size of created jar ﬁles
N representing the number of original jar ﬁles. Given N ,we create a jar ﬁle t through the steps in Algorithm 2. It
starts with an empty jar ﬁle. The line 3 randomly selects rithat provides at least one new class of a new component tot. Two jar ﬁles are regarded as diﬀerent versions of the same
component if they have the same ﬁle path except for theirversion number parts. The line 4 copies class ﬁles without
overwriting a class ﬁle already copied to t.
The selected jar ﬁles for t form a goldset for t: G(t) ={r1 , · · · , rN }. In addition to the jar ﬁles, we construct a
set of ﬁles V (t) such that each jar ﬁle v ∈ V (t) includes
the same set of ﬁles copied at Step 4. In other words,
jar ﬁles in V (t) are possible code origins that could provide their classes to t. Since a jar ﬁle in G(t) also satisﬁes
the condition, V (t) ⊇ G(t) holds. For example, suppose
commons-httpclient-3.1 is selected as ri and its 167 classﬁles are copied to t, Then, V (t) includes the ﬁle and anotherjar ﬁle named org.apache.servicemix.bundles.commonshttpclient-3.1_4, because the archive also contains thesame 167 class ﬁles. We identify such jar ﬁles by searching ﬁle hash values in all the jar ﬁles in R.
We vary the size of a jar ﬁle N from 10 to 1,000 by 10.
For each N , we create 10 jar ﬁles. Hence, our dataset T
includes 1,000 target jar ﬁles.
As an overview of the created jar ﬁles, the numbers ofclasses in the ﬁles are shown in Figure 2. The smallest jar
ﬁle contains 196 classes, the maximum one contains 159,104
classes. The median is 56,304. We believe N = 1, 000 andthe number of classes are suﬃciently large to include the sizeof a practical application; for example, Eclipse IDE for Java
Developers 4.4.1 comprises 519 jar ﬁles. For each selectedﬁle, at least one class has been copied. The median and the
maximum number of copied classes per selected ﬁle are 15
and 36,189, respectively. 58.1% of selected jar ﬁles provided
classes that are unique to the jar ﬁles. On average, 4.6
jar ﬁles include the same ﬁle set. 3.4% of selected ﬁles are

1.0
0.8
Precision

Table 1: Accuracy of the methods under comparison
MethodP recision P recisionjar Recall
Our method (Full)
0.998
0.803
0.997
Bert+Greedy
0.997
0.678
0.997
Bert+Sig
0.357
0.231
0.994
Bertillonage
0.357
0.207
0.993

0.6
0.4
0.2

partially copied, because their contents overlap with alreadycopied ﬁles. In those cases, 42.4% of class ﬁles in a selected
ﬁle are not copied on average.

Full|{Ji ∈ D|Ji ∩ G(t) = φ}|P recision(t, D) =|D|
A high precision indicates that a user can trust the reported
set.
Even though jar ﬁles in Ji have the same class signatures,the classes may have diﬀerent contents. For example, achange of a boolean operator in a conditional predicate does
not aﬀect a class signature but changes the binary. In such acase, even if Ji includes a correct answer, a user might haveto identify one of them in the set. To analyze this eﬀort,
we deﬁne another precision P recisionjar to represent how
many jar ﬁles in Ji have a copy of the actually copied ﬁles.
| Ji ∈D Ji ∩ V (t)|P recisionjar (t, D) =| Ji ∈D Ji |If this precision is high, Ji includes less variants. A user caneasily obtain the original ﬁles.
Recall represents how many original jar ﬁles are detected,
while precision indicates how many reported ﬁles are correct.
If an element in the goldset is not involved in any Ji ∈ D,
it is a false negative. Hence, recall of a list D is deﬁned asfollows.
| Ji ∈D Ji ∩ G(t)|Recall(t, D) =|G(t)|A high recall is important for users to investigate the result,because the number of existing components is too large formanual investigation.

4.4 Result
Table 1 summarizes the precisions and recall evaluated on
the whole detection result for the created dataset. While
we show the details later, all the metrics of our method are
higher than Software Bertillonage ones, and the diﬀerences
are statistically signiﬁcant.
Figure 3 shows box plots indicating precision of the methods. The Full and Bert+Greedy versions achieved signiﬁcantly higher precision than Bertillonage. The mean pre-Bert+Sig

Bertillonage

Figure 3: Distribution of P recision

4.3 Accuracy
15#False positives

We evaluate accuracy of our method by precision and recall. Given a jar ﬁle t, each of the methods under comparison reports a list of detected jar ﬁle sets D = J1 , · · · , J|D| .
Each ﬁle set Ji indicates that some classes are reused fromone of the jar ﬁles in it. For example, J = {r1 , r2 } represents
that “ﬁles are copied from either r1 or r2 .” We classify a set
Ji to true positive if G(t) ∩ Ji = φ. The set Ji is classiﬁed
to false positive if G(t) ∩ Ji = φ. Based on the classiﬁcation,
we deﬁne the precision of a list D as follows.

Bert+Greedy

1050
10−200210−400410−600

610−800

810−1000N

Figure 4: The number of false positives of the Fullversion of our method

cision of our method is 0.998, while one of Bertillonage is
0.357. Kolmogorov-Smirnov test indicated that the four distributions are normal (all p values are less than 10−6 ). A
paired t-test shows that the mean diﬀerence 0.641 between
our method and Bertillonage is signiﬁcant (p < 10−10 ).
The diﬀerence is caused by our greedy algorithm. Since acomponent sometimes includes an internal copy of its dependent library, a target ﬁle has a certain degree of similarity
to other components including the same library and the library itself. Our algorithm links a class to at most one setof jar ﬁles, while a simple similarity-based list includes all
the candidates as-is.
Our class signature does not contribute to this precision.
Although a paired t-test shows the diﬀerence between the
Full and Bert+Greedy versions is statistically signiﬁcant(p < 10−10 ), the actual diﬀerence is very small (less than0.1%).
The number of false positives of our method is very small
but correlated to the number of jar ﬁles in a target jar ﬁle(N ). The correlation coeﬃcient between them is 0.670. Figure 4 shows the distribution of the numbers. Our method
generated the precise result (P recision(t) = 1) for 406 jar
ﬁles. False positives are often reported when a combinationof copied jar ﬁles is recognized as another jar ﬁle. For example, classes included in grizzly-comet 2.1.6 and grizzlyhttp-server-core 2.1.11 are detected as a copy of grizzly-comet-server 2.1.11. The falsely recognized jar ﬁle actually contains the exact copy of the class ﬁles. Similarly, aversion of org.apache.aries.jmx.core is recognized as thesame version of org.apache.aries.jmx. These are common
cases because a project often releases a small set of classes

1.00

0.8

0.98

0.6

0.96

RecallPrecision (jar)

1.0

0.4

0.94

0.2

0.92

0.0

0.90
Full

Bert+Greedy

Bert+Sig

Bertillonage

Full

Figure 5: P recisionjar computed on all the reported
jar ﬁlesBert+Greedy

Bert+Sig

Bertillonage

Figure 7: Distribution of Recall

1000
Time (sec.)

Precision (jar)

1.0
0.8
0.6
0.4

800
600
400
200

0.2

0

0.0

10−20010−200210−400410−600

610−800

210−400

810−1000

410−600

610−800

810−1000

NN

Figure 8: Time to analyze a jar ﬁle for diﬀerent N
Figure 6: P recisionjar of the Full version of our
method for diﬀerent N

as a core component and its superset as another component.
Figure 5 shows the distributions of P recisionjar . As indicated in the ﬁgure, the Full version of our method is more
precise than the Bert+Greedy version. Kolmogorov-Smirnov
test indicated that the four distributions are normal (p =0.019, 0.004, 0.001, and 0.003, respectively). A paired t-testshows that the precision of the Full method is signiﬁcantly
higher than Bert+Greedy (p < 10−14 ), and the mean diﬀerence is 0.126. Hence, our class signature contributes to identify original jar ﬁles more accurately, by reducing a chanceof an accidental match.
The boxplot also shows that our method may report alarge number of false positive jars. The false positives arecaused by a particular jar ﬁle. An example jar ﬁle causing
the worst P recisionjar in the ﬁgure is org.glassfish.hk2.
test-harness 1.6.10. The jar ﬁle and its consecutive versions (1.6.11 and 1.6.12) include the same six ﬁles. Givena target ﬁle t includes a copy of the ﬁle, our method reports that the same classes are included in 196 versionsof com.sun.enterprise.test-harness (e.g. 0.3.19–0.3.101
and 1.0.0-1.0.75) in addition to the original ﬁles. We regarded them as false positives, because they have diﬀerent
ﬁle hash values from the copied class ﬁles. Our signaturebased comparison cannot distinguish them.
The ratio of false positive jars are not aﬀected by the number of original jar ﬁles in a target ﬁle (N ). Figure 6 shows
the distributions of the P recisionjar of our Full method for
diﬀerent N ranges. The correlation coeﬃcient between thenumber of false positive jars and the number of jar ﬁles N
is -0.097. Hence, the false positive jars are not caused by a

combination of jar ﬁles.
Figure 7 shows Recall of the methods. The mean recall of
our Full method is 0.997, while the Bertillonage is 0.993. All
the methods result in high recall, because we do not use athreshold to excluding less similar jar ﬁles from the analysis.
The mean diﬀerence between our method and Bertillonage
is only 0.004, though a paired t-test shows that the diﬀerence is signiﬁcant. Our method can be seen as an automatic
selection of jar ﬁles to improve precision, while slightly improving recall.
The original jar ﬁles are missing in our result because
multiple original jar ﬁles are falsely recognized as a diﬀerent
jar ﬁle. Hence, the number of false negatives is correlated
to the number of false positives. The correlation coeﬃcientis 0.635.

4.5

Performance

We used a workstation equipped with two six core processors (Intel Xeon E5-2620 2.0GHz) and RAM 64GB. We
implemented the signature extraction step as a concurrent
process. It took 28.1 minutes to analyze 172,232 jar ﬁles in
the repository using 20 threads. The extracted class signatures are compressed and stored in binary ﬁles. Their total
size is 1.0GiB. The size is much smaller than the original
repository data that occupies 77.8GiB.
Figure 8 plots the time cost of our method to analyze atarget jar ﬁle using the signature database. The time includes an entire execution of a tool: Reading the signature
data from ﬁles, extracting signatures from a target jar ﬁle,comparing the signatures, and generating a report ﬁle. The
longest time spent for a target jar ﬁle is 16.6 minutes using
a single thread. The time cost is practical to verify compo-

Table 2: A part of the ouptut of our method applied
to FacebookLinkBench.jar
Jar ﬁle (#Classes)
jruby-complete-1.6.5 (7673),
jruby-1.6.5 (7673)
hbase-0.94.3 (2269)
guava-16.0.1 (1678)
jmxutils-1.16 (1415)
hadoop-core-0.20.2 (1376)
org.mortbay.jetty.jsp-2.1.6.1.14 (585)commons-collections-3.2.1 (458)org.jbundle.util.osgi.wrapped.
org.apache.http.client-4.1.2 (436)jackson-mapper-asl-1.8.8 (432),
jackson-mapper-lgpl-1.8.8 (432)
log4j-1.2.17 (314)org.apache.bval.bundle-0.4 (220)commons-httpclient-3.0.1 (148)
slf4j-log4j12-1.4.3 (6)bval-bval-jsr303-0.5 (173)
slf4j-simple-1.7.0 (6)#Copied
7673
2269
1678
1415
1376
490
458
436
432
314
215
148
6
5
3

nents actually included in every release candidate. We also
expect that the time is much shorter than manual analysis
to exclude false positives (60% on average) from Software
Bertillonage results.

5. APPLICATION OF COMPONENT DETECTION
To demonstrate a usefulness of our method, we have applied our method to analyze two existing jar ﬁles. The ﬁrst
case represents a release engineering situation that comparesthe dependencies managed by developers with components
actually included in a product. The second case assesses
a risk of a product whose components are unrecorded bydevelopers.

5.1 Facebook LinkBench
Facebook Linkbench [14] is a benchmark program. It uses
Maven to download dependent components and create an
executable jar ﬁle. We analyzed FacebookLinkBench.jar
that was built using our workstation on December 2015.
Since the code has been released on April 2013, we haveadded newer jar ﬁles in the Maven Central Repository to
our repository in prior to the analysis.
Our method reported 89 jar ﬁle sets as code origins for
FacebookLinkBench.jar. Table 2 shows a snippet of theoutput. In the table, ﬁle names are shortened for readability. Each ﬁle name is followed by a number indicating thenumber of classes in the ﬁle. The second column #Copied
indicates the number of classes found in the target jar ﬁle.
For example, our method reported that 7673 classes in thetarget jar ﬁles are copied from either jruby-complete-1.6.5
or jruby-1.6.5. The copy is likely an entire jar ﬁle, because
both jar ﬁles include 7673 classes. Similarly, 78 of 89 arereported as entirely copied jar ﬁles.
The jar ﬁles jackson-mapper-asl and jackson-mapper-lgpl
include the same classes under diﬀerence license (ASL and

LGPL as indicated in their names). Our method cannot
distinguish one from the other.
Our method reported org.apache.bval.bundle-0.4 and bvalbval-jsr303-0.5. They are diﬀerent versions of relevant components. Since the project website [1] explicitly declares
the bundle component includes bval-core and bval-jsr303,
bundle-0.4 is likely a false positive of either bundle-0.5 orbval-core-0.5.
The pom.xml ﬁle of the project declares 10 dependent components such as hadoop, hbase, log4j, and slf4j-simple. Allof them are identiﬁed by our method. An interesting observation is found in org/slf4j/impl package. The package includes nine classes copied from slf4j-log4j12 and slf4j-simple.
Each jar ﬁle includes six classes. However, they include different versions of the same classes: StaticLoggerBinder,
StaticMarkerBinder, and StaticMDCBinder. These classes
in slf4j-simple are not copied, because another deﬁnition of
the three classes are copied from slf4j-log4j12. The StaticLoggerBinder class is used to deﬁne which logger classes
are used in a program. Since the target jar includes a copy
from slf4j-log4j12, the program always uses log4j. Anotherlogger class in slf4j-simple is never used, even though it isexplicitly declared as a dependency.
In addition to the declared dependencies, the output of our
method includes transitively dependent components. In Table 2, a variant of org.apache.http.client 4.1.2 and commonshttpclient 3.0.1 are included. The former one is a newer
version of the latter one, but already outdated. A security
vulnerability allows a man-in-the-middle attack [33]. Another component commons-collections-3.2.1 is also marked
as vulnerable today [2].
While our method identiﬁes components directly includedin the target jar ﬁle, we can analyze the inside of the detectedcomponents by temporarily removing the components fromthe database. For example, our method identiﬁed a copy of
Joda-Time 1.6.2 in jruby-1.6.5.
The analysis of the LinkBench jar could be hard if we used
Software Bertillonage alone, because the similarity metric
reported that 610 components are either entirely or partially
included in the jar ﬁle. Nevertheless, Software Bertillonage
is also still useful, if a user is interested in a particular component. For example, suppose a user would like to know if atarget jar ﬁle includes vulnerable versions of Apache Standard Taglib that allow remote attackers to execute arbitrarycode [34]. In such a case, the user can quickly scan the target jar ﬁle using the similarity metric. Indeed, the similarity
metric reported that Apache Standard Taglib 1.2.0, a vulnerable version, is likely included in the application jar ﬁle.
While the component name does not appear in the dependencies declared by developers, our method automatically
identiﬁed jsp-2.1-6.1.14 as the origin of the class ﬁles in the
package org/apache/taglibs. The information gives a hint
for developers to update their dependencies.

5.2

muCommander 0.9.0

muCommander 0.9.0 is a ﬁle manager that can manipulate
both local and remote ﬁles. In the source code repository[31], lib directory is unavailable in the revision tagged as
release_0_9_0. Since third-party components for 0.8.5 arepreserved in the revision release_0_8_5, we added the ﬁlesto the repository to analyze components in 0.9.0.
Our method reported 34 jar ﬁle sets for 0.9.0. Table 3
shows a part of the result. In the table, libraries in the lib

Table 3: A part of the ouptut of our method applied
to muCommander 0.9.0
Jar ﬁle (#Classes)
0.8.5/jna (148)
0.8.5/icu4j (54)commons-httpclient-3.1-beta1 (166)
commons-httpclient-3.1 (167),
0.8.5/commons-httpclient (167)
0.8.5/jcifs (247)
0.8.5/j2ssh (294)logback-classic-1.0.2 (155)
logback-core-1.0.2 (261)#Copied
148
18
61
2
29
67
30
48

directory of 0.8.5 are indicated by a preﬁx “0.8.5/”. According to the result, libraries used in 0.8.5 including JNA,ICU4J, jCIFS, and J2SSH are not updated for 0.9.0. Our
method reported that commons-httpclient in the release islikely 3.1-beta1, rather than 3.1. This is probably because
the copied ﬁles are modiﬁed from the original ﬁles in 3.1,
although the diﬀerence is unrecorded.
The analysis result does not include some libraries suchas commons-logging and J7Zip that are included in 0.8.5.
Hence, they are likely removed from the version. Logback
1.0.2 is a logging library that is likely introduced in this version. However, the library names in README are inconsistent to the analysis result. The README still contains
J7Zip but nothing about Logback.
In the case of muCommander 0.9.0, there is no oﬃcialrecord of library versions. The project uses JDK 1.4; all theclasses in the jar ﬁle have diﬀerent MD5 ﬁle hash values fromclasses in the repository. Our signature-based comparison
successfully identiﬁed candidates of original jar ﬁles in such asituation. The result indicates that the product uses several
old lbiraries but the actual state is not provided to users of
the product.

6. THREATS TO VALIDITY
Our method uses a signature-based comparison. The definition of a class signature is an extended version of [8, 9];method calls and ﬁeld access in methods are added. Our signature deﬁnition assumed that compilers generate the same
numbers of method calls and ﬁeld access from the same
source code. Although we believe existing compilers suchas Oracle JDK and Eclipse JDT satisfy the condition, it is
not ensured by Java language speciﬁcation. For example, acompiler may generate optimized code (e.g. loop unrolling)including additional method calls. Hence, the method still
has a risk to miss existing components.
We have used a snapshot of the Maven repository as arepository of existing components. Although the repository
covers various components, precision and recall are aﬀectedby the jar ﬁles stored in the repository. It should be notedthat our method is not dependent on Maven. We have usedartifact names in the repository only for creating the goldset
for the experiment.
The experiment evaluates accuracy on an ideal repositorythat includes all existing components. The eﬀect of an unknown component is dependent on its content. If all theclasses are unique to the component, it is simply unrecog-

nized. If a copy of a class is included in a jar ﬁle in therepository, the jar ﬁle is reported as a false positive.
The goldset is artiﬁcially created by a random selectionof components. It does not take the popularity of components into account. In addition, it may include an unrealistic
combination, e.g. incompatible components.
When creating the goldset for the experiment, we used
SHA-1 ﬁle hash to identify jar ﬁles containing a copy ofclasses. A ﬁle hash value is dependent on a compiler and its
conﬁguration in addition to source code. Hence, we could
miss class ﬁles compiled for a diﬀerent JDK version. Since acomponent having a diﬀerent ﬁle hash is regarded as a false
positive, we might underestimate P recisionjar reported by
the methods under comparison.
The goldset ﬁles are created by copying entire ﬁles. A
jar ﬁle is partially copied only when the same classes are
already copied from another ﬁle. The process emulates asimple black-box reuse style; Maven Assembly Plugin also
creates an all-in-one jar ﬁle in a similar way. While 3.4%of selected ﬁles are partially copied in the experiment, theratio might be diﬀerent from actual reuse activity.

7.

CONCLUSION

Reuse of third party components is an important activity
in software development. On the other hand, developers andusers have to be aware of components and their versions in
products to analyze security issues, update the components,
and check a license. In this paper, we proposed a method toautomatically detect jar ﬁles whose class ﬁles are included
in a target program. Using a greedy algorithm, our method
reports a list of jar ﬁles. While our method may reportmultiple jar ﬁles containing the same classes, 99.8% of thereported sets include a correct ﬁle. In addition, 80.3% of thejar ﬁles in the sets include the copied ﬁles.
We have applied our method to two applications: Facebook LinkBench and muCommander. The method identiﬁed vulnerable components included in the products in bothﬁles. It also identiﬁed a component that was improperly
copied to the LinkBench jar ﬁle and a component that is
not documented in muCommander. The reported lists ofcomponents enable developers and users to assess potential
risks caused by the components in the applications.
Our implementation of the method is available online.1
In future work, we would like to extend our method to
identify renamed and/or customized components in a product. Since our method uses identiﬁer names, analysis of the
impact of code obfuscation is also important. Another direction is an improvement of empirical studies on library migrations and code reuse activities in practice. For example,
we can count the number of dependent components reusedin a binary, ignoring their internal components. This kind of
statistics might enable developers and managers to identify
popular and/or valuable components in their organization.

Acknowledgments
This work is supported by JSPS KAKENHI Grant Numbers
25220003, 26280021, and 15H02683. This work is also supported by Osaka University Program for Promoting International Joint Research, “Software License Evolution Analysis.”1

https://github.com/takashi-ishio/JIngredients

8. REFERENCES[1] Apache BVal Project. Project modules.
http://bval.apache.org/mvnsite/modules.html(Accessed January 29, 2016).
[2] Apache Commons Collections. Arbitrary remote code
execution with InvokerTransformer, 2015. https://issues.apache.org/jira/browse/COLLECTIONS-580.
[3] Apache Maven Project. Apache maven assemblyplugin. http://maven.apache.org/plugins/maven-assembly-plugin/.
[4] V. Bauer and B. Hauptmann. Assessing Cross-Project
Clones for Reuse Optimization. In Proceedings of theInternational Workshop on Software Clones, pages
60–61, 2013.
[5] G. Bavota, G. Canfora, M. D. Penta, R. Oliveto, and
S. Panichella. The Evolution of ProjectInter-dependencies in a Software Ecosystem: The Caseof Apache. In Proceedings of the 29th IEEE
International Conference on Software Maintenance,
pages 280–289, 2013.
[6] K. Chen, P. Liu, and Y. Zhang. Achieving Accuracy
and Scalability Simultaneously in Detecting
Application Clones on Android Markets. In
Proceedings of the 36th IEEE/ACM International
Conference on Software Engineering, 2014.
[7] L. Constantin. Developers often unwittingly use
components that contain ﬂaws. ITWorld.com,
http://www.itworld.com/article/2936575/security/
software-applications-have-on-average-24vulnerabilities-inherited-from-buggy-components.html[Posted June 16, 2015].
[8] J. Davies, D. M. German, M. W. Godfrey, and
A. Hindle. Software bertillonage: Finding theprovenance of an entity. In Proceedings of the 8th
Working Conference on Mining Software Repositories,
pages 183–192, 2011.
[9] J. Davies, D. M. German, M. W. Godfrey, and
A. Hindle. Software bertillonage: Determining theprovenance of software development artifacts.
Empirical Software Engineering, 18:1195–1237, 2013.
[10] M. Di Penta, D. M. German, and G. Antoniol.
Identifying licensing of jar archives using a code-search
approach. In Proceedings of the 7th Working
Conference on Mining Software Repositories, pages
151–160, 2010.
[11] J. Dietrich, K. Jezek, and P. Brada. Broken Promises:
An Empirical Study into Evolution Problems in Java
Programs Caused by Library Upgrades. In Proceedingsof the IEEE CSMR-WCRE 2014 Software Evolution
Week, pages 64–73, 2014.
[12] S. Duszynski, J. Knodel, and M. Becker. Analyzing
the source code of multiple software variants for reusepotential. In Proceedings of the 18th IEEE Working
Conference on Reverse Engineering, pages 303–307,
2011.
[13] Eclipse Documentation. Runnable jar ﬁle exporter.
http://help.eclipse.org/luna/index.jsp?topic=%2Forg.
eclipse.jdt.doc.user%2Ftasks%2Ftasks-37.htm.
[14] Facebook Engineering. Linkbench: A databasebenchmark for the social graph, 2013. https://www.facebook.com/notes/facebook-engineering/
linkbench-a-database-benchmark-for-the-social-graph/10151391496443920/.
[15] S. Fischer, L. Linsbauer, R. E. Lopez-Herrejon, andA. Egyed. Enhancing clone-and-own with systematicreuse for developing software variants. In Proceedingsof the 30th IEEE International Conference on
Software Maintenance and Evolution, pages 391–400,
2014.
[16] D. M. German and M. D. Penta. A Method for Open
Source License Compliance of Java Applications.
IEEE Software, 29(3):58–63, 2012.
[17] D. M. German, M. D. Penta, Y.-G. Guéhéneuc, and
G. Antoniol. Code siblings: Technical and legal
implications of copying code between applications. In
Proceedings of the 6th Working Conference on Mining
Software Repositories, pages 81–90, 2009.
[18] GWT Project. Getting started.
http://www.gwtproject.org/gettingstarted.html.
[19] L. Heinemann, F. Deissenboeck, M. Gleirscher,
B. Hummel, and M. Irlbeck. On the extent and natureof software reuse in open source java projects. In
Proceedings of the 12th International Conference on
Software Reuse, volume 6727 of Lecture Notes in
Computer Science, pages 207–222, 2011.
[20] A. Hemel, K. T. Kalleberg, R. Vermaas, and
E. Dolstra. Finding software license violations throughbinary code clone detection. In Proceedings of the 8th
Working Conference on Mining Software Repositories,
pages 63–72, 2011.
[21] A. Hemel and R. Koschke. Reverse Engineering
Variability in Source Code Using Clone Detection: A
Case Study for Linux Variants of Consumer Electronic
Devices. In Proceedings of the 19th IEEE Working
Conference on Reverse Engineering, pages 357–366,
2012.
[22] K. Inoue, Y. Sasaki, P. Xia, and Y. Manabe. Where
does this code come from and where does it go? –integrated code history tracker for open source
systems –. In Proceedings of the 34th IEEE/ACM
International Conference on Software Engineering,
pages 331–341, 2012.
[23] T. Kamiya, S. Kusumoto, and K. Inoue. CCFinder: amultilinguistic token-based code clone detection
system for large scale source code. IEEE Transactions
on Software Engineering, 28(7):654–670, 2002.
[24] T. Kanda, T. Ishio, and K. Inoue. Extraction of
product evolution tree from source code of productvariants. In Proceedings of the 17th International
Software Product Line Conference, pages 141–150,
Tokyo, Japan, 2013. ACM.
[25] N. Kawamitsu, T. Ishio, T. Kanda, R. G. Kula, C. De
Roover, and K. Inoue. Identifying source code reuseacross repositories using LCS-based source code
similarity. In Proceedings of the 14th International
Working Conference on Source Code Analysis andManipulation, pages 305–314, 2014.
[26] R. G. Kula, C. De Roover, D. German, T. Ishio, andK. Inoue. Visualizing the evolution of systems andtheir library dependencies. In Proceedings of the 2ndIEEE Working Conference on Software Visualization,
pages 127–136, 2014.
[27] C. Lopes, S. Bajracharya, J. Ossher, and P. Baldi.
UCI source code data sets, 2010.

http://www.ics.uci.edu/˜lopes/datasets/.
[28] L. Luo, J. Ming, D. Wu, P. Liu, and S. Zhu.
Semantics-based obfuscation-resilient binary code
similarity comparison with applications to software
plagiarism detection. In Proceedings of the 22nd ACM
SIGSOFT International Symposium on Foundationsof Software Engineering, pages 389–400, 2014.
[29] P. Mohagheghi, R. Conradi, O. Killi, and H. Schwarz.
An empirical study of software reuse vs. defect-density
and stability. In Proceedings of the 26th International
Conference on Software Engineering, pages 282–291,
May 2004.
[30] I. J. Mojica, B. Adams, M. Nagappan, S. Dienst,
T. Berger, and A. Hassan. A large-scale empirical
study on software reuse in mobile apps. IEEE
Software, 31(2):78–86, 2014.
[31] muCommander Project. Subversion Repository ofmuCommander.
https://svn.mucommander.com/mucommander/(Accessed January 29, 2016).
[32] National Vulnerability Database. CVE-2014-0107,
2014. https://web.nvd.nist.gov/view/vuln/detail?
vulnId=CVE-2014-0107.
[33] National Vulnerability Database. CVE-2014-3577,
2014. https://web.nvd.nist.gov/view/vuln/detail?
vulnId=CVE-2014-3577.
[34] National Vulnerability Database. CVE-2015-0254,
2015. https://web.nvd.nist.gov/view/vuln/detail?
vulnId=CVE-2015-0254.
[35] J. Qiu, X. Su, and P. Ma. Library functions
identiﬁcation in binary code by using graphisomorphism testings. In Proceedings of the 22ndIEEE International Conference on Software Analysis,
Evolution, and Reengineering, pages 261–270, 2015.
[36] S. Raemaekers, A. van Deursen, and J. Visser.
Semantic versioning versus breaking changes: A studyof the maven repository. In Proceedings of the 14th
IEEE International Working Conference on Source
Code Analysis and Manipulation, pages 215–224, 2014.
[37] J. Rubin, K. Czarnecki, and M. Chechik. Managing
cloned variants: A framework and experience. In
Proceedings of the 17th International Software ProductLine Conference, pages 101–110, August 2013.
[38] A. Sæbjørnsen, J. Willcock, T. Panas, D. Quinlan,
and Z. Su. Detecting code clones in binary
executables. In Proceedings of the 18th ACM
International Symposium on Software Testing andAnalysis, pages 117–128. ACM, 2009.
[39] M. Sojer and J. Henkel. License risks from ad hocreuse of code from the internet. Communications of
the ACM, 54(12):74–81, 2011.
[40] D. Steidl, B. Hummel, and E. Juergens. Incremental
Origin Analysis of Source Code Files. In Proceedingsof the 11th Working Conference on Mining Software
Repositories, pages 42–51, 2014.
[41] C. Teyton, J.-R. Falleri, M. Palyart, and X. Blanc. A
study of library migrations in java. Journal of
Software: Evolution and Process, 26(11):1030–1052,
2014.
[42] F. Thung, D. Lo, and J. L. Lawall. Automated library
recommendation. In Proceedings of the 20th IEEE
Working Conference on Reverse Engineering, pages

182–191, 2013.
[43] Y. Yano, R. G. Kula, T. Ishio, and K. Inoue.
Verxcombo: An interactive data visualization of
popular library version combinations. In Proceedingsof the 23rd IEEE International Conference on
Program Comprehension, pages 291–294, 2015.