Understanding and Analyzing Java Reflection

TL;DR

This paper provides a comprehensive analysis of Java reflection and introduces SOLAR, a static analysis tool that improves soundness and precision in resolving reflection in large Java programs, aiding bug detection and security analysis.

Contribution

It offers a detailed understanding of Java reflection and presents a new static analysis approach implemented in SOLAR, enhancing reflection resolution accuracy and usability.

Findings

SOLAR resolves reflection more soundly than existing tools.

It accurately identifies imprecise reflection resolutions.

It guides iterative refinement of analysis results with lightweight annotations.

Abstract

Java reflection has been increasingly used in a wide range of software. It allows a software system to inspect and/or modify the behaviour of its classes, interfaces, methods and fields at runtime, enabling the software to adapt to dynamically changing runtime environments. However, this dynamic language feature imposes significant challenges to static analysis, because the behaviour of reflection-rich software is logically complex and statically hard to predict, especially when manipulated frequently by statically unknown string values. As a result, existing static analysis tools either ignore reflection or handle it partially, resulting in missed, important behaviours, i.e., unsound results. Therefore, improving or even achieving soundness in (static) reflection analysis -- an analysis that infers statically the behaviour of reflective code -- will provide significant benefits to many analysis clients, such as bug detectors, security analyzers and program verifiers. This paper makes two contributions: we provide a comprehensive understanding of Java reflection through examining its underlying concept, API and real-world usage, and, building on this, we introduce a new static approach to resolving Java reflection effectively in practice. We have implemented our reflection analysis in an open-source tool, called SOLAR, and evaluated its effectiveness extensively with large Java programs and libraries. Our experimental results demonstrate that SOLAR is able to (1) resolve reflection more soundly than the state-of-the-art reflection analysis; (2) automatically and accurately identify the parts of the program where reflection is resolved unsoundly or imprecisely; and (3) guide users to iteratively refine the analysis results by using lightweight annotations until their specific requirements are satisfied.

Tables

						c.newInstance			ct.newInstance			invoke		get/set
		Doopr	Elf	Solar	Doopr	Elf	Solar	Doopr	Elf	Solar	Doopr	Elf	Solar
chart	Recall	13	21	22	2	2	2	2	2	2	8	8	8
	TamiFlex		22			2			2			8
eclipse	Recall	9	24	37	1	3	3	2	7	7	8	1039	1039
	TamiFlex		37			3			7			1039
fop	Recall	9	12	13	0	0	0	1	1	1	8	8	8
	TamiFlex		13			0			1			8
hsqldb	Recall	5	9	10	1	1	1	0	0	0	8	8	8
	TamiFlex		10			1			0			8
pmd	Recall	4	8	13	0	0	0	0	0	7	8	8	8
	TamiFlex		13			0			7			8
xalan	Recall	36	42	43	0	0	0	32	5	32	8	8	8
	TamiFlex		43			0			32			8
avrora	Recall	50	46	53	0	0	0	0	0	0	0	0	0
	TamiFlex		53			0			0			0
checkstyle	Recall	7	9	72	1	1	24	1	5	28	8	8	8
	TamiFlex		72			24			28			8
findbugs	Recall	6	10	15	8	8	115	1	1	1	8	8	8
	TamiFlex		15			115			1			8
freecs	Recall	6	10	12	2	2	2	1	1	55	8	8	8
	TamiFlex		12			2			55			8
Total	Recall	141	191	290	15	17	147	40	22	133	72	1103	1103
	TamiFlex		290			147			133			1103

Equations

$$MTD({\text{m}}_s^t)$$

$$FLD({\text{f}}_s^t)$$

$$AllKwn(v)$$

$$SC(\text{m.invoke(y,args)})=AllKwn(\text{y})\vee \forall {\text{m}}_s^u\in pt(\text{m}):s.n_m\ne u\wedge Ptp(\text{args})\ne \varnothing$$

$$SC(\text{(A)f.get(y)})=AllKwn(\text{y})\vee \forall {\text{f}}_s^u\in pt(\text{f}):s.n_f\ne u\wedge \text{A}\ne \text{Object}$$

$$SC(\text{f.set(y,x)})=AllKwn(\text{y})\vee \forall {\text{f}}_s^u\in pt(\text{f}):s.n_f\ne u\wedge AllKwn(\text{x})$$

Full text

This paper makes two contributions: we provide a comprehensive understanding of Java reflection through examining its underlying concept, API and real-world usage, and, building on this, we introduce a new static approach to resolving Java reflection effectively in practice. We have implemented our reflection analysis in an open-source tool, called Solar, and evaluated its effectiveness extensively with large Java programs and libraries. Our experimental results demonstrate that Solar is able to (1) resolve reflection more soundly than the state-of-the-art reflection analysis; (2) automatically and accurately identify the parts of the program where reflection is resolved unsoundly or imprecisely; and (3) guide users to iteratively refine the analysis results by using lightweight annotations until their specific requirements are satisfied.

††terms: Object-Oriented Programming Languages, Program Analysis

1 Introduction

Java reflection allows a software system to inspect and/or modify the behaviour of its classes, interfaces, methods and fields at runtime, enabling the software to adapt to dynamically changing runtime environments. This dynamic language feature eases the development and maintenance of Java programs in many programming tasks by, for example, facilitating their flexible integration with the third-party code and their main behaviours to be configured according to a deployed runtime environment in a decoupled way. Due to such advantages, reflection has been widely used in a variety of Java applications and frameworks [Li et al. (2014), Zhauniarovich et al. (2015)].

Static analysis is widely recognized as a fundamental tool for bug detection [Engler et al. (2001), Naik et al. (2006)], security vulnerability analysis [Livshits and Lam (2005), Arzt et al. (2014)], compiler optimization [Dean et al. (1995), Sui et al. (2013)], program verification [Das et al. (2002), Blanchet et al. (2003)], and program debugging and understanding [Sridharan et al. (2007), Li et al. (2016)]. However, when applying static analysis to Java programs, reflection poses a major obstacle [Livshits et al. (2005), Li et al. (2014), Li et al. (2015), Smaragdakis et al. (2015)]. If the behavior of reflective code is not resolved well, much of the codebase will be rendered invisible for static analysis, resulting in missed, important behaviours, i.e., unsound analysis results [Livshits et al. (2015)]. Therefore, improving or even achieving soundness in (static) reflection analysis—an analysis that infers statically the behavior of reflective code—will provide significant benefits to all the client analyses as just mentioned above.

1.1 Challenges

Developing effective reflection analysis for real-world programs remains a hard problem, widely acknowledged by the static analysis community [Livshits et al. (2015)]:

``Reflection usage and the size of libraries/frameworks make it very difficult to scale points-to analysis to modern Java programs.'' [(57)];

``Reflection makes it difficult to analyze statically.'' [Rastogi et al. (2013)];

``In our experience [Ernst et al. (2014)], the largest challenge to analyzing Android apps is their use of reflection …'' [Barros et al. (2015)]

``Static analysis of object-oriented code is an exciting, ongoing and challenging research area, made especially challenging by dynamic language features, a.k.a. reflection.'' [Landman et al. (2017)]

There are three reasons on why it is hard to untangle this knotty problem:

• •

The Java reflection API is large and its common uses in Java programs are complex. It remains unclear how an analysis should focus on its effort on analyzing which of its reflection methods in order to achieve some analysis results as desired.

• •

The dynamic behaviours of reflective calls are mainly specified by their string arguments, which are usually unknown statically (e.g., with some string values being encrypted, read from configuration files, or retrieved from the Internet).

• •

The reflective code in a Java program cannot be analyzed alone in isolation. To resolve reflective calls adequately, a reflection analysis often works inter-dependently with a pointer analysis [Livshits et al. (2005), Li et al. (2014), Li et al. (2015), Smaragdakis and Balatsouras (2015), Smaragdakis et al. (2015)], with each being both the producer and consumer of the other. When some reflective calls are not yet resolved, the pointer information that is currently available can be over- or under-approximate. Care must be taken to ensure that the reflection analysis helps increase soundness (coverage) while still maintaining sufficient precision for the pointer analysis. Otherwise, the combined analysis would be unscalable for large programs.

As a result, most of the papers on static analysis for object-oriented languages, like Java, treat reflection orthogonally (often without even mentioning its existence). Existing static analysis tools either ignore reflection or handle it partially and ineffectively.

1.2 Previous Approaches

Initially, reflection analysis mainly relies on string analysis, especially when the string arguments to reflective calls are string constants, to resolve reflective targets, i.e., methods or fields reflectively accessed. Currently, this mainstream approach is still adopted by many static analysis tools for Java, such as Soot, Wala, Chord and Doop. However, as described in Section 1.1, string analysis will fail in many situations where string arguments are unknown, resulting in limited soundness and precision. As a static analysis, a (more) sound reflection analysis is one that allows (more) true reflective targets (i.e., targets that are actually accessed at runtime) to be resolved statically. In practice, any reflection analysis must inevitably make a trade-off among soundness, precision, scalability, and (sometimes) automation.

In addition, existing reflection analyses [Livshits et al. (2005), Bravenboer and Smaragdakis (2009), Smaragdakis et al. (2015), Barros et al. (2015), Li et al. (2016), Zhang et al. (2017)] cannot answer two critical questions that are raised naturally, in practice: Q(1) how sound is a given reflection analysis and Q(2) which reflective calls are resolved unsoundly or imprecisely? We argue for their importance as follows:

• •

If Q(1) is unanswered, users would be unsure (or lose confidence) about the effectiveness of the analysis results produced. For example, a bug detector that reports no bugs may actually miss many bugs if some reflective calls are resolved unsoundly.

• •

If Q(2) is unanswered, users would not have an opportunity to contribute in improving the precision and soundness of the analysis results, e.g., by providing some user annotations. For some client analyses (e.g., verification), soundness is required.

1.3 Contributions

In this paper, we attempt to uncover the mysterious veil of Java reflection and change the informed opinion in the program analysis community about static reflection analysis: ``Java reflection is a dynamic feature which is nearly impossible to handle effectively in static analysis''. We make the following contributions:

• •

We provide a comprehensive understanding of Java reflection through examining its underlying concept (what it is), interface (how its API is designed), and real-world usage (how it is used in practice). As a result, we will provide the answers to several critical questions, which are somewhat related, including:

• –

What is reflection, why is it introduced in programming languages, and how is Java reflection derived from the basic reflection concept?

• –

Which methods of the Java reflection API should be analyzed carefully and how are they related, as the API is large and complex (with about 200 methods)?

• –

How is reflection used in real-world Java programs and what can we learn from its common uses? We have conducted a comprehensive study about reflection usage in a set of 16 representative Java programs by examining their 1,423 reflective call sites. We report 7 useful findings to enable the development of improved practical reflection analysis techniques and tools in future research.

• •

We introduce a new static analysis approach, called Solar (soundness-guided reflection analysis), to resolve Java reflection effectively in practice. As shown in Figure 1, Solar has three unique advantages compared with previous work:

• –

Solar is able to yield significantly more sound results than the state-of-the-art reflection analysis. In addition, Solar allows its soundness to be reasoned about when some reasonable assumptions are met.

• –

Solar is able to accurately identify the parts of the program where reflection is analyzed unsoundly or imprecisely, making it possible for users to be aware of the effectiveness of their analysis results (as discussed in Section 1.2).

• –

Solar provides a mechanism to guide users to iteratively refine the analysis results by adding lightweight annotations until their specific requirements are satisfied, enabling reflection to be analyzed in a controlled manner.

• •

We have implemented Solar in Doop [Bravenboer and Smaragdakis (2009)] (a state-of-the-art pointer analysis tool for Java) and released it as an open-source tool. In particular, Solar can output its reflection analysis results with the format that is supported by Soot (a popular framework for analyzing Java and Android applications), allowing Soot's clients to use Solar's results directly.

• •

We conduct extensive experiments on evaluating Solar's effectiveness with large Java applications and libraries. Our experimental results provide convincing evidence on the ability of Solar in analyzing Java reflection effectively, in practice.

1.4 Organization

The rest of this paper is organized as follows. We will start by providing a comprehensive understanding of Java reflection in Section 2. Building on this understanding, we give an overview of Solar in Section 3 and introduce its underlying methodology in Section 4. Then, we formalize Solar in Section 5, describe its implementation in Section 6, and evaluate its effectiveness in Section 7. Finally, we discuss the related work in Section 8 and conclude in Section 9.

2 Understanding Java Reflection

Java reflection is a useful but complex language feature. To gain a deep understanding about Java reflection, we examine it in three steps. First, we describe what Java reflection is, why we need it, and how it is proposed (Section 2.1). Second, we explain how Java reflection is designed to be used, i.e., its API (Section 2.2). Finally, we investigate comprehensively how it has been used in real-world Java applications (Section 2.3). After reading this section, the readers are expected to develop a whole picture about the basic mechanism behind Java reflection, understand its core API design, and capture the key insights needed for developing practical reflection analysis tools.

2.1 Concept

Reflection, which has long been studied in philosophy, represents one kind of human abilities for introspecting and learning their nature. Accordingly, a (non-human) object can also be endowed with the capability of such self-awareness. This arises naturally in artificial intelligence: ``Here I am walking into a dark room. Since I cannot see anything, I should turn on the light". As explained in [Sobel and Friedman (1996)], such thought fragment reveals a self-awareness of behaviour and state, one that leads to a change in that selfsame behaviour and state, which allows an object to examine itself and make use of the meta-level information to decide what to do next.

Similarly, when we enable programs to avail themselves of such reflective capabilities, reflective programs will also allow the programs to observe and modify properties of their own behaviour. Thus, let a program be self-aware — this is the basic motivation of the so-called computational reflection, which is also considered as the reflection used in the area of programming languages [Demers and Malenfant (1995)].

In the rest of this section, we will introduce what computational reflection is (Section 2.1.1), what reflective abilities it supports (Section 2.1.2), and how Java reflection is derived from it (Section 2.1.3).

2.1.1 Computational Reflection

Reflection, as a concept for computational systems, dates from Brian Smith's doctoral dissertation [Smith (1982)]. Generally, as shown in Figure 2(a), a computational system is related to a domain and it answers questions about and/or support actions in the domain [Maes (1987)]. Internally, a computational system incorporates both the data that represents entities and relations in the domain and a program that describes how these data may be manipulated.

A computational system $\mathcal{S}$ is said to be also a reflective system, as shown in Figure 2(b), if the following two conditions are satisfied:

• •

First, the system $\mathcal{S}$ has its own representation, known as its self-representation or metasystem, in its domain as a kind of data to be examined and manipulated.

• •

Second, the system $\mathcal{S}$ and its representation are causally connected: a change to the representation implies a change to the system, and vice versa.

The base system $\mathcal{S}$ should be reified into its representation before its metasystem can operate. Then the metasystem examines and manipulates its behaviour using the reified representation. If any changes are made by the metasystem, then the effects will also be reflected in the behavior of the corresponding base system.

2.1.2 Reflective Abilities

Generally, (computational) reflection is the ability of a program to examine and modify the structure and behavior of a program at runtime [Herzeel et al. (2008), Malenfant et al. (1996)]. Thus, it endows the program the capabilities of self-awareness and self-adapting. These two reflective abilities are known as introspection and intercession, respectively, and both require a reification mechanism to encode a program's execution state as data first [Demers and Malenfant (1995)].

• •

Introspection: the ability of a program to observe, and consequently, reason about its own execution state.

• •

Intercession: the ability of a program to modify its own execution state or alter its own interpretation or meaning.

Providing full reflective abilities as shown above is hardly acceptable in practice, as this will introduce both implementation complexities and performance problems [Chiba (2000)]. Thus, in modern programming languages like Java, reflective abilities are only partially supported [Forman and Forman (2004), Bracha and Ungar (2004)].

2.1.3 Java Reflection

Java reflection supports introspection and very limited intercession. In particular, an introspection step is usually followed by behaviour changes such as object creation, method invocation and attribute manipulation111Some other researchers hold a different view that Java reflection does not support intercession at all [Bracha and Ungar (2004), Donkervoet and Agha (2007)], as they adopt a more strict definition of intercession, which implies the ability to modify the self-representation of a program. [Cazzola (2004), Forman and Forman (2004)].

Despite its limited reflective abilities, Java reflection is able to allow programmers to break the constraints of staticity and encapsulation, making the program adapt to dynamically changing runtime environments. As a result, Java reflection has been widely used in real-world Java applications to facilitate flexibly different programming tasks, such as reasoning about control (i.e., about which computations to pursue next) [Forman and Forman (2004)], interfacing (e.g., interaction with GUIs or database systems) [Gestwicki and Jayaraman (2002), Rashid and Chitchyan (2003)], and self-activation (e.g., through monitors) [Dawson et al. (2008)].

Java reflection does not have a reify operation as described in Section 2.1.1 (Figure 2(b)) to turn the basic (running) system (including stack frames) into a representation (data structure) that is passed to a metasystem. Instead, a kind of metarepresentation, based on metaobjects, exists when the system begins running and persists throughout the execution of the system [Forman and Forman (2004)].

A metaobject is like the reflection in a mirror: one can adjust one's smile (behaviour changes) by looking at oneself in a mirror (introspection). In Section 2.2, we will look at how Java reflection uses metaobjects and its API to facilitate reflective programming.

2.2 Interface

We first use a toy example to illustrate some common uses of the Java reflection API (Section 2.2.1). We then delve into the details of its core methods, which are relevant to (and thus should be handled by) any reflection analysis (Section 2.2.2).

2.2.1 An Example

There are two kinds of metaobjects: Class objects and member objects. In Java reflection, one always starts with a Class object and then obtain its member objects (e.g., Method and Field objects) from the Class object by calling its corresponding accessor methods (e.g., getMethod() and getField()).

In Figure 3, the metaobjects clz, mtd and fld are instances of the metaobject classes Class, Method and Field, respectively. Constructor can be seen as Method except that the method name ``<init>'' is implicit. Class allows an object to be created reflectively by calling newInstance(). As shown in line 4, the dynamic type of obj is the class (type) represented by clz (specified by cName). In addition, Class provides accessor methods such as getDeclaredMethod() in line 5 and getField() in line 7 to allow the member metaobjects (e.g., of Method and Field) related to a Class object to be introspected. With dynamic invocation, a Method object can be commanded to invoke the method that it represents (line 6). Similarly, a Field object can be commanded to access or modify the field that it represents (lines 8 and 9).

2.2.2 Core Java Reflection API

In reflection analysis, we are concerned with reasoning about how reflection affects the control and data flow information in the program. For example, if a target method (say $m$) that is reflectively invoked in line 6 in Figure 3 cannot be resolved statically, the call graph edge from this call site to method $m$ (control flow) and the values passed interprocedurally from obj and a to this and the parameter of $m$ (data flow), respectively, will be missing. Therefore, we should focus on the part of the Java reflection API that affects a pointer analysis, a fundamental analysis that statically resolves the control and data flow information in a program [Livshits et al. (2005), Li et al. (2014), Smaragdakis et al. (2015), Lhoták and Hendren (2003), Milanova et al. (2005), Smaragdakis et al. (2011), Tan et al. (2016), Tan et al. (2017)].

It is thus sufficient to consider only the pointer-affecting methods in the Java reflection API. We can divide such reflective methods into three categories (Figure 3):

• •

Entry methods, which create Class objects, e.g., forName() in line 3 in Figure 3.

• •

Member-introspecting methods, which introspect and retrieve member metaobjects, i.e., Method (Constructor) and Field objects from a Class object, e.g., getDeclaredMethod() in line 5 and getField() in line 7 in Figure 3.

• •

Side-effect methods, which affect the pointer information in the program reflectively, e.g., newInstance(), invoke(), get() and set() in lines 4, 6, 8 and 9 in Figure 3 for creating an object, invoking a method, accessing and modifying a field, respectively.

Entry Methods

Class objects are returned by entry methods, as everything in Java reflection begins with Class objects. There are many entry methods in the Java reflection API. In Figure 3, only the four most widely used ones are listed explicitly.

Note that forName() (loadClass()) returns a Class object representing a class that is specified by the value of its string argument. The Class object returned by $o$.getClass() and $A$.class represents the dynamic type (class) of $o$ and $A$, respectively.

Member-Introspecting Methods

Class provides a number of accessor methods for retrieving its member metaobjects, i.e., the Method (Constructor) and Field objects. In addition, these member metaobjects can be used to introspect the methods, constructors and fields in their target class. Formally, these accessor methods are referred to here as the member-introspecting methods.

As shown in Figure 3, for each kind of member metaobjects, there are four member-introspecting methods. We take a Method object as an example to illustrate these methods, whose receiver objects are the Class objects returned by the entry methods.

• •

getDeclaredMethod(String, Class[]) returns a Method object that represents a declared method of the target Class object with the name (formal parameter types) specified by the first (second) parameter (line 5 in Figure 3).

• •

getMethod(String, Class[]) is similar to getDeclaredMethod(String, Class[]) except that the returned Method object is public (either declared or inherited). If the target Class does not have a matching method, then its superclasses are searched first recursively (bottom-up) before its interfaces (implemented).

• •

getDeclaredMethods() returns an array of Method objects representing all the methods declared in the target Class object.

• •

getMethods() is similar to getDeclaredMethods() except that all the public methods (either declared or inherited) in the target Class object are returned.

Side-Effect Methods

As shown in Figure 3, a total of nine side-effect methods that can possibly modify or use (as their side effects) the pointer information in a program are listed. Accordingly, Table 2.2.2 explains how these methods affect the pointer information by giving their side effects on the pointer analysis.

In Figure 3, the first five side-effect methods use four kinds of metaobjects as their receiver objects while the last four methods use Class or Array objects as their arguments. Below we briefly examine them in the order given in Table 2.2.2.

• •

The side effect of newInstance() is allocating an object with the type specified by its metaobject clz or ctor (say $A$) and initializing it via a constructor of $A$, which is the default constructor in the case of Class::newInstance() and the constructor specified explicitly in the case of Constructor::newInstance().

• •

The side effect of invoke() is a virtual call when the first argument of invoke(), say $o$, is not null. The receiver object is $o$ as shown in the ``Side Effect'' column in Table 2.2.2. When $o$ is null, invoke() should be a static call.

• •

The side effects of get() and set() are retrieving (loading) and modifying (storing) the value of a instance field, respectively, when their first argument, say $o$, is not null; otherwise, they are operating on a static field.

• •

The side effect of newProxyInstance() is creating an object of a proxy class Proxy$*, and this proxy class is generated dynamically according to its arguments (containing a Class object). Proxy.newProxyInstance() can be analyzed according to its semantics. A call to this method returns a Proxy object, which has an associated invocation handler object that implements the InvocationHandler interface. A method invocation on a Proxy object through one of its Proxy interfaces will be dispatched to the invoke() method of the object's invocation handler.

• •

The side effect of Array.newInstance() is creating an array (object) with the component type represented by the Class object (e.g., clz in Table 2.2.2) used as its first argument. Array.get() and Array.set() are retrieving and modifying an index element in the array object specified as their first argument, respectively.

2.3 Reflection Usage

The Java reflection API is rich and complex. We have conducted an empirical study to understand reflection usage in practice in order to guide the design and implementation of a sophisticated reflection analysis described in this paper. In this section, we first list the focus questions in Section 2.3.1, then describe the experimental setup in Section 2.3.2, and finally, present the study results in Section 2.3.3.

2.3.1 Focus Questions

We consider to address the following seven focus questions in order to understand how Java reflection is used in the real world:

• •

Q1. The core part of reflection analysis is to resolve all the nine side-effect methods (Table 2.2.2) effectively. What are the side-effect methods that are most widely used and how are the remaining ones used in terms of their relative frequencies?

• •

Q2. The Java reflection API contains many entry methods for returning Class objects. Which ones should be focused on by an effective reflection analysis?

• •

Q3. Existing reflection analyses resolve reflection by analyzing statically the string arguments of entry and member-introspecting method calls. How often are these strings constants and how often can non-constant strings be resolved by a simple string analysis that models string operations such as ``+'' and append()?

• •

Q4. Existing reflection analyses ignore the member-introspecting methods that return an array of member metaobjects. Is it necessary to handle such methods?

• •

Q5. Existing reflection analyses usually treat reflective method calls and field accesses as being non-static. Does this treatment work well in real-world programs? Specifically, how often are static reflective targets used in reflective code?

• •

Q6. In [Livshits et al. (2005)], intraprocedural post-dominating cast operations are leveraged to resolve newInstance() when its class type is unknown. This approach is still adopted by many reflection analysis tools. Does it generally work in practice?

• •

Q7. What are new insights on handling Java reflection (from this paper)?

2.3.2 Experimental Setup

We have selected a set of 16 representative Java programs, including three popular desktop applications, javac-1.7.0, jEdit-5.1.0 and Eclipse-4.2.2 (denoted Eclipse4), two popular server applications, Jetty-9.0.5 and Tomcat-7.0.42, and all eleven DaCapo benchmarks (2006-10-MR2) [Blackburn et al. (2006)]. Note that the DaCapo benchmark suite includes an older version of Eclipse (version 3.1.2). We exclude its bloat benchmark since its application code is reflection-free. We consider lucene instead of luindex and lusearch separately since these two benchmarks are derived from lucene with the same reflection usage.

We consider a total of 191 methods in the Java reflection API (version 1.6), including the ones mainly from package java.lang.reflect and class java.lang.Class.

We use Soot [Vallée-Rai et al. (1999)] to pinpoint the calls to reflection methods in the bytecode of a program. To understand the common reflection usage, we consider only the reflective calls found in the application classes and their dependent libraries but exclude the standard Java libraries. To increase the code coverage for the five applications considered, we include the jar files whose names contain the names of these applications (e.g., jetty.jar for Jetty) and make them available under the process-dir option supported by Soot. For Eclipse4, we use org.eclipse.core. runtime.adaptor.EclipseStarter to let Soot locate all the other jar files used.

We manually inspect the reflection usage in a program in a demand-driven manner, starting from its side-effect methods, assisted by Open Call Hierarchy in Eclipse, by following their backward slices. For a total of 609 side-effect call sites examined, 510 call sites for calling entry methods and 304 call sites for calling member-introspecting methods are tracked and analyzed. As a result, a total of 1,423 reflective call sites, together with some nearby statements, are examined in our study.

2.3.3 Results

Below we describe our seven findings on reflection usage as our answers to the seven focus questions listed in Section 2.3.1, respectively. We summarize our findings as individual remarks, which are expected to be helpful in guiding the development of practical reflection analysis techniques and tools in future research.

Q1. Side-Effect Methods

Figure 5 depicts the percentage frequency distribution of all the nine side-effect methods in all the programs studied. We can see that newInstance() and invoke() are the ones that are most frequently used (46.3% and 32.7%, respectively, on average). Both of them are handled by existing static analysis tools such as Doop, Soot, Wala and Bddbddb. However, Field- and Array-related side-effect methods, which are also used in many programs, are ignored by most of these tools. To the best of our knowledge, they are handled only by Elf [Li et al. (2014)], Solar [Li et al. (2015)] and Doop [Smaragdakis et al. (2015)]. Note that newProxyInstance() is used in jEdit only in our study and a recent survey on reflection analysis [Landman et al. (2017)] reports more its usages in the real world.

Remark 1. Reflection analysis should at least handle newInstance() and invoke() as they are the most frequently used side-effect methods (79% on average), which will significantly affect a program's behavior, in general; otherwise, much of the codebase may be invisible for analysis. Effective reflection analysis should also consider Field- and Array-related side-effect methods, as they are also commonly used.

Q2. Entry Methods

Figure 6 shows the percentage frequency distribution of eight entry methods. *Unknown*'' is included since we failed to find the entry methods for some side-effect calls (e.g., invoke()) even by using Eclipse's *Open Call Hierarchy* tool. For the first 12 programs, the six entry methods as shown (excluding Unknown'' and *Others*'') are the only ones leading to side-effect calls. For the last two, Jetty and Tomcat, Others'' stands for defineClass() in ClassLoader and getParameterTypes() in Method. Finally, getComponentType() is usually used in the form of getClass().getComponentType() for creating a Class object argument for Array.newInstance().

On average, Class.forName(), .class, getClass() and loadClass() are the top four most frequently used (48.1%, 18.0%, 17.0% and 9.7%, respectively). A class loading strategy can be configured in forName() and loadClass(). In practice, forName() is often used by the system class loader and loadClass() is usually overwritten in customer class loaders, especially in framework applications such as Tomcat and Jetty.

Remark 2. Reflection analysis should handle Class.forName(), getClass(), .class, and loadClass(), which are the four major entry methods for creating Class objects. In addition, getComponentType() should also be modeled if Array-related side-effect methods are analyzed, as they are usually used together.

Q3. String Constants and String Manipulations

In entry methods, Class.forName() and loadClass() each have a String parameter to specify the target class. In member-introspecting methods, getDeclaredMethod(String,...) and getMethod(String,...) each return a Method object named by its first parameter; getDeclaredField(String) and getField(String) each return a Field object named by its single parameter.

As shown in Figure 7, string constants are commonly used when calling the two entry methods (34.7% on average) and the four member-introspecting methods (63.1% on average). In the presence of string manipulations, many class/method/field names are unknown exactly. This is mainly because their static resolution requires precise handling of many different operations e.g., subString() and append(). In fact, many cases are rather complex and thus cannot be handled well by simply modeling the java.lang.String-related API. Thus, Solar does not currently handle string manipulations. However, the incomplete information about class/method/field names (i.e., partial string information) can be exploited beneficially [Smaragdakis et al. (2015)].

We also found that many string arguments are Unknown (55.3% for calling entry methods and 25.1% for calling member-introspecting methods, on average). These are the strings that may be read from, say, configuration files, command lines, or even Internet URLs. Finally, string constants are found to be more frequently used for calling the four member-introspecting methods than the two entry methods: 146 calls to getDeclaredMethod() and getMethod(), 27 calls to getDeclaredField() and getField() in contrast with 98 calls to forName() and loadClass(). This suggests that the analyses that ignore string constants flowing into some member-introspecting methods may fail to exploit such valuable information and thus become imprecise.

Remark 3. Resolving reflective targets by string constants does not always work. On average, only 49% reflective call sites (where string arguments are used to specify reflective targets) use string constants. In addition, fully resolving non-constant string arguments by string manipulation, although mentioned elsewhere [Livshits et al. (2005), Bodden et al. (2011)], may be hard to achieve, in practice.

Q4. Retrieving an Array of Member Objects

As introduced in Section 2.2.2, half of member-introspecting methods (e.g., getDeclaredMethods()) return an array of member metaobjects. Although not as frequently used as the ones returning single member metaobject (e.g., getDeclaredMethod()), they play an important role in introducing new program behaviours in some applications. For example, in the two Eclipse programs studied, there are four invoke() call sites called on an array of Method objects returned from getMethods() and 15 fld.get() and fld.set() call sites called on an array of Field objects returned by getDeclaredFields(). Through these calls, dozens of methods are invoked and hundreds of fields are modified reflectively. Ignoring such methods as in prior work [Livshits et al. (2005)] and tools (Bddbddb, Wala, Soot) may lead to significantly missed program behaviours by the analysis.

Remark 4. In member-introspecting methods, get(Declared)Methods/Fields/Constructors(), which return an array of member metaobjects, are usually ignored by most of existing reflection analysis tools. However, they play an important role in certain applications for both method invocations and field manipulations.

Q5. Static or Instance Members

In the literature on reflection analysis [Livshits et al. (2005), Li et al. (2014), Smaragdakis et al. (2015)], reflective targets are mostly assumed to be instance members. Accordingly, calls to the side-effect methods such as invoke(), get() and set(), are usually considered as virtual calls, instance field accesses, and instance field modifications, respectively (see Table 2.2.2 for details). However, in real programs, as shown in Figure 8, on average, 37% of the invoke() call sites are found to invoke static methods and 50% of the get()/set() call sites are found to access/modify static fields. Thus in practice, reflection analysis should distinguish both cases and also be aware of whether a reflective target is a static or instance member, since the approaches for resolving both cases are usually different.

Remark 5. Static methods/fields are invoked/accessed as frequently as instance methods/fields in Java reflection, even though the latter has received more attention in the literature. In practice, reflection analysis should distinguish the two cases and adopt appropriate approaches for handling them.

Q6. Resolving newInstance() by Casts

In Figure 3, when cName is a not string constant, the (dynamic) type of obj created by newInstance() in line 4 is unknown. For this case, Livshits et al. [Livshits et al. (2005)] propose to infer the type of obj by leveraging the cast operation that post-dominates intra-procedurally the newInstance() call site. If the cast type is A, the type of obj must be A or one of its subtypes assuming that the cast operation does not throw any exceptions. This approach has been implemented in many analysis tools such as Wala, Bddbddb and Elf.

However, as shown in Figure 9, exploiting casts this way does not always work. On average, 28% of newInstance() call sites have no such intra-procedural post-dominating casts. As newInstance() is the most widely used side-effect method, its unresolved call sites may significantly affect the soundness of the analysis, as discussed in Section 7.5.1. Hence, we need a better solution to handle newInstance().

Remark 6. Resolving newInstance() calls by leveraging their intra-procedural post-dominating cast operations fails to work for 28% of the newInstance() call sites found. As newInstance() affects critically the soundness of reflection analysis (Remark 1), a more effective approach for its resolution is required.

Q7. Self-Inferencing Property

As illustrated by the program given in Figure 3, the names of its reflective targets are specified by the string arguments (e.g., cName, mName and fName) at the entry and member-introspecting reflective calls. Therefore, string analysis has been a representative approach for static reflection analysis in the last decade. However, if the value of a string is unknown statically (e.g., read from external files or command lines), then the related reflective calls, including those to newInstance(), may have to be ignored, rendering the corresponding codebase or operations invisible to the analysis. To improve precision, in this case, the last resort is to exploit the existence of some intra-procedurally post-dominating cast operations on a call to newInstance() in order to deduce the types of objects reflectively created ($Q6$).

However, in our study, we find that there are many other rich hints about the behaviors of reflective calls at their usage sites. Such hints can be and should be exploited to make reflection analysis more effective, even when some string values are partially or fully unknown. In the following, we first look at three real example programs to examine what these hints are and expose a so-called self-inferencing property inherent in these hints. Finally, we explain why self-inferencing property is pervasive for Java reflection and discuss its potential in making reflection analysis more effective.

Example 2.1** **(Reflective Method Invocation

(Figure 10)).

The method name (the first argument of getMethod() in line 174) is statically unknown as part of it is read from command line cmd. However, the target method (represented by method) can be deduced from the second argument (parameters) of the corresponding side-effect call invoke() in line 175. Here, parameters is an array of objects, with only one element (line 155). By querying the pointer analysis and also leveraging the type information in the program, we know that the type of the object pointed to by this is FrameworkCommandInterpreter, which has no subtypes. As a result, we can infer that the descriptor of the target method in line 175 must have only one argument and its declared type must be FrameworkCommandInterpreter or one of its supertypes.

Example 2.2** (Reflective Field Access (Figure 11)).**

In this program, factoryField (line 1683) is obtained as a Field object from an array of Field objects created in line 1653 for all the fields in URLConnection. In line 1687, the object returned from get() is cast to java.net.ContentHandlerFactory. Based on its cast operation and null argument, we know that the call to get() may only access the static fields of URLConnection with the type java.net.ContentHandlerFactory, its supertypes or its subtypes. Otherwise, all the fields in URLConnection must be assumed to be accessed conservatively.

Example 2.3** (Reflective Field Modification (Figure 12)).**

Like the case in Figure 11, the field object in line 290 is also read from an array of field objects created in line 302. This code pattern appears one more time in line 432 in the same class, i.e., org.eclipse.osgi.util.NLS. According to the two arguments, null and value, provided at set() (line 290), we can deduce that the target field (to be modified in line 290) is static (from null) and its declared type must be java.lang.String or one of its supertypes (from the type of value).

Definition 2.4** (Self-Inferencing Property).**

For each side-effect call site, where reflection is used, all the information of its arguments (including the receiver object), i.e., the number of arguments, their types, and the possible downcasts on its returned values, together with the possible string values statically resolved at its corresponding entry and member-introspecting call sites, forms its self-inferencing property.

We argue that the self-inferencing property is a pervasive fact about Java reflection, due to the characteristics of object-oriented programming and the Java reflection API. As an example, the declared type of the object (reflectively returned by get() and invoke() or created by newInstance()) is always java.lang.Object. Therefore, the object returned must be first cast to a specific type before it is used as a regular object, except when its dynamic type is java.lang.Object or it will be used only as an receiver for the methods inherited from java.lang.Object; otherwise, the compilation would fail. As another example, the descriptor of a target method reflectively called at invoke() must be consistent with what is specified by its second argument (e.g., parameters in line 176 of Figure 10); otherwise, exceptions would be thrown at runtime. These constraints should be exploited to enable resolving reflection in a disciplined way.

The self-inferencing property not only helps resolve reflective calls more effectively when the values of string arguments are partially known (e.g., when either a class name or a member name is known), but also provides an opportunity to resolve some reflective calls even if the string values are fully unknown. For example, in some Android apps, class and method names for reflective calls are encrypted for benign or malicious obfuscation, which ``makes it impossible for any static analysis to recover the reflective call'' [Rastogi et al. (2013)]. However, this appears to be too pessimistic in our setting, because, in addition to the string values, some other self-inferencing hints are possibly available to facilitate reflection resolution. For example, given (A)invoke(o, {...}), the class type of the target method can be inferred from the dynamic type of o (by pointer analysis). In addition, the declared return type and descriptor of the target method can also be deduced from A and {...}, respectively, as discussed above.

Remark 7. * Self-inferencing property is an inherent and pervasive one in the reflective code of Java programs. However, this property has not been fully exploited in analyzing reflection before. We will show how this property can be leveraged in different ways (for analyzing different kinds of reflective methods as shown in Sections 4.2 and 4.3) in order to make reflection analysis significantly more effective. *

3 Overview of Solar

We first introduce the design goal of, challenges faced by, and insights behind Solar in Section 3.1. We then present an overview of the Solar framework including its basic working mechanism and the functionalities of its components in Section 3.2.

3.1 Goals, Challenges and Insights

Design Goal

As already discussed in Section 1.3, Solar is designed to resolve reflection as soundly as possible (i.e., more soundly or even soundly when some reasonable assumptions are met) and accurately identify the reflective calls resolved unsoundly.

Challenges

In addition to the challenges described in Section 1.1, we must also address another critical problem: it is hard to reason about the soundness of Solar and identify accurately which parts of the reflective code have been resolved unsoundly.

If one target method at one reflective call is missed by the analysis, it may be possible to identify the statements that are unaffected and thus still handled soundly. However, the situation will deteriorate sharply if many reflective calls are resolved unsoundly. In the worst case, all the other statements in the program may be handled unsoundly. To play safe, the behaviors of all statements must be assumed to be under-approximated in the analysis, as we do not know which value at which statement has been affected by the unsoundly resolved reflective calls.

Insights

To achieve the design goals of Solar, we first need to ensure that as few reflective calls are resolved unsoundly as possible. This will reduce the propagation of unsoundness to as few statements as possible in the program. As a result, if Solar reports that some analysis results are sound (unsound), then they are likely sound (unsound) with high confidence. This is the key to enabling Solar to achieve practical precision in terms of both soundness reasoning and unsoundness identification.

To resolve most or even all reflective calls soundly, Solar needs to maximally leverage the available information (the string values at reflective calls are inadequate as they are often unknown statically) in the program to help resolve reflection. Meanwhile, Solar should resolve reflection precisely. Otherwise, Solar may be unscalable due to too many false reflective targets introduced. In Sections 4.2 and 4.3, we will describe how Solar leverages the self-inferencing property in a program (Definition 2.4) to analyze reflection with good soundness and precision.

Finally, Solar should be aware of the conditions under which a reflective target cannot be resolved. In other words, we need to formulate a set of soundness criteria for different reflection methods based on different resolution strategies adopted. If the set of criteria is not satisfied, Solar can mark the corresponding reflective calls as the ones that are resolved unsoundly. Otherwise, Solar can determine the soundness of the reflection analysis under some reasonable assumptions (Section 4.1).

3.2 The Solar Framework

Figure 13 gives an overview of Solar. Solar consists of four core components: an inference engine for discovering reflective targets, an interpreter for soundness and precision, a locater for unsound and imprecise calls, and a Probe (a lightweight version of Solar). In the rest of this section, we first introduce the basic working mechanism of Solar and then briefly explain the functionality of each of its components.

3.2.1 Working Mechanism

Given a Java program, the inference engine resolves and infers the reflective targets that are invoked or accessed at all side-effect method call sites in the program, as soundly as possible. There are two possible outcomes. If the reflection resolution is scalable (under a given time budget), the interpreter will proceed to assess the quality of the reflection resolution under soundness and precision criteria. Otherwise, Probe, a lightweight version of Solar, would be called upon to analyze the same program again. As Probe resolves reflection less soundly but much more precisely than Solar, its scalability can be usually guaranteed. We envisage providing a range of Probe variants with different trade-offs among soundness, precision and scalability, so that the scalability of Probe can be always guaranteed.

If the interpreter confirms that the soundness criteria are satisfied, Solar reports that the reflection analysis is sound. Otherwise, the locater will be in action to identify which reflective calls are resolved unsoundly. In both cases, the interpreter will also report the reflective calls that are resolved imprecisely if the precision criteria are violated. This allows potential precision improvements to be made for the analysis.

The locater not only outputs the list of reflective calls that are resolved unsoundly or imprecisely in the program but also pinpoints the related entry and member-introspecting method calls of these ``problematic'' calls, which contain the hints to guide users to add annotations, if possible. Figure 14 depicts an example output.

As will be demonstrated in Section 7, for many programs, Solar is able to resolve reflection soundly under some reasonable assumptions. However, for certain programs, like other existing reflection analyses, Solar is unscalable. In this case, Probe (a lightweight version of Solar whose scalability can be guaranteed as explained above) is applied to analyze the same program. Note that Probe is also able to identify the reflective calls that are resolved unsoundly or imprecisely in the same way as Solar. Thus, with some unsound or imprecise reflective calls identified by Probe and annotated by users, Solar will re-analyze the program, scalably after one or more iterations of this ``probing'' process. As discussed in Section 7, the number of such iterations is usually small, e.g., only one is required for most of the programs evaluated.

For some programs, users may choose not to add annotations to facilitate reflection analysis. Even in this case, users can still benefit from the Solar approach, for two reasons. First, Probe is already capable of producing good-quality reflection analysis results, more soundly than string analysis. Second, users can understand the quality of these results by inspecting the locater's output, as discussed in Section 1.2.

3.2.2 Basic Components

Their functionalities are briefly explained below.

Reflective Target Inference Engine

We employ two techniques to discover reflective targets: collective inference for resolving reflective method invocations (invoke()) and field accesses/modifications (get()/set()) and lazy heap modeling for handling reflective object creation (newInstance()). Both techniques exploit the self-inferencing property found in our reflection usage study (Section 2.3.3) to resolve reflection in a disciplined manner with good soundness and precision. We will explain their approaches in Sections 4.2 and 4.3, respectively, and further formalize them in Section 5.4.

Soundness and Precision Interpreter

Solar currently adopts a simple but practical scheme to measure precision, in terms of the number of targets resolved at a side-effect call site. Solar allows users to specify a threshold value in advance to define the imprecision that can be tolerated for each kind of side-effect calls, forming its precision criteria. Its soundness criteria are formulated in terms of conditions under which various inference rules (adopted by the inference engine) can be applied soundly. We will formalize the soundness criteria required in Section 5.5.

Unsound and Imprecise Call Locater

A side-effect reflective call is identified as being imprecisely resolved if the number of resolved targets is higher than permitted by its corresponding precision criterion. Similarly, a side-effect reflective call is marked as being unsoundly resolved if its corresponding soundness criterion is violated.

To facilitate user annotations for an imprecisely or unsoundly resolved side-effect reflective call, the locater also pinpoints its corresponding entry and member-introspecting method call sites. It can be difficult to understand the semantics of a reflective call by reading just the code at its vicinity. Often, more hints about its semantics are available at or around its entry and member-introspecting method call sites, which may reside in different methods or even classes in the program.

Example 3.1**.**

Figure 14 illustrates Solar's output for a real program. The invoke() (side-effect method) call site in method getValue is the unsoundly resolved call identified. Its entry method (forName()) and member-introspecting method (getMethods()) call sites, which are located in the constructor of class org.hsqldb.Function, are also highlighted. At the right-hand side of the figure, we can see that the hints for annotations are available around the entry and member-introspecting call sites (e.g., lines 169, 184 and 185) rather than the side-effect call site (line 352). This demonstrates the usefulness of Solar's annotation strategy.

We will further explain how Solar identifies unsoundly resolved reflective calls in Section 4.4 and how users are guided to add annotations in Section 4.5.

Probe

Probe is a lightweight version of Solar by weakening the power of its inference engine. Probe changes its inference strategies in both collective inference and lazy heap modeling, by resolving reflection more precisely but less soundly. Thus, the scalability of Probe can be usually guaranteed as fewer false reflective targets are introduced. We will formalize Probe based on the formalism of Solar in Section 5.7.

4 The Solar Methodology

We first define precisely a set of assumptions made (Section 4.1). Then we examine the methodologies of collective inference (Section 4.2) and lazy heap modeling (Section 4.3) used in Solar's inference engine. Finally, we explain how Solar identifies unsoundly resolved reflective calls (Section 4.4) and how doing so helps guide users to add lightweight annotations to facilitate a subsequent reflection analysis (Section 4.5).

4.1 Assumptions

There are four reasonable assumptions. The first one is commonly made on static analysis [Sonntag and Colnet (2014)] and the next two are made previously on reflection analysis for Java [Livshits et al. (2005)]. Solar adds one more assumption to allow reflective allocation sites to be modeled lazily. Under the four assumptions, it becomes possible to reason about the soundness and imprecision of Solar.

Assumption 1** **(Closed-World)

Only the classes reachable from the class path at analysis time can be used during program execution.

This assumption is reasonable since we cannot expect static analysis to handle all classes that a program may download from the Internet and load at runtime. In addition, Java native methods are excluded as well.

Assumption 2** **(Well-Behaved Class Loaders)

The name of the class returned by a call to Class.forName(cName) equals cName.

This assumption says that the class to be loaded by Class.forName(cName) is the expected one specified by the value of cName, thus avoiding handling the situation where a different class is loaded by, e.g., a malicious custom class loader. How to handle custom class loader statically is still an open hard problem. Note that this assumption also applies to loadClass(), another entry method shown in Figure 3.

Assumption 3** **(Correct Casts)

Type cast operations applied to the results of calls to side-effect methods are correct, without throwing a ClassCastException.

This assumption has been recently demonstrated as practically valid through extensive experiments in [Landman et al. (2017)].

Assumption 4** **(Object Reachability)

Every object o created reflectively in a call to newInstance() flows into (i.e., will be used in) either (1) a type cast operation …= (T) v or (2) a call to a side-effect method, get(v), set(v,…) or invoke(v,…), where v points to o, along every execution path in the program.

Cases (1) and (2) represent two kinds of usage points at which the class types of object $o$ will be inferred lazily. Specifically, case (1) indicates that $o$ is used as a regular object, and case (2) says that $o$ is used reflectively, i.e., flows to the first argument of different side-effect calls as a receiver object. This assumption does not cover only one rare situation where $o$ is created but never used later. As validated in Section 7.2, Assumption 4 is found to hold for almost all reflective allocation sites in the real code.

4.2 Collective Inference

Figure 15 gives an overview of collective inference for handling reflective method invocations and field accesses/modifications. Essentially, we see how the side-effect method calls invoke(), get() and set() are resolved. A Class object $\mathcal{C}$ is first created for the target class named cName. Then a Method (Field) object $\mathcal{M}$ ($\mathcal{F}$) representing the target method (field) named mName (fName) in the target class of $\mathcal{C}$ is created. Finally, at some reflective call sites, e.g., invoke(), get() and set(), the target method (field) is invoked (accessed) on the target object o, with the arguments, {...} or a.

Solar works as part of a pointer analysis, with each being both the producer and consumer of the other. By exploiting the self-inferencing property (Definition 2.4) inherent in the reflective code, Solar employs the following two component analyses:

Target Propagation (Marked by Solid Arrows)

Solar resolves the targets (methods or fields) of reflective calls, invoke(), get() and set(), by propagating the names of their target classes and methods/fields (e.g., those pointed by cName, mName and fName if statically known) along the solid lines into the points symbolized by circles.

Target Inference (Marked by Dashed Arrows)

By using Target Propagation alone, a target member name (blue circle) or its target class type (red circle) at a reflective call site may be missing, i.e., unknown, due to the presence of input-dependent strings (Figure 7). If the target class type (red circle) is missing, Solar will infer it from the dynamic type of the target object o (obtained by pointer analysis) at invoke(), get() or set() (when o != null). If the target member name (blue circle) is missing, Solar will infer it from (1) the dynamic types of the arguments of the target call, e.g., {...} of invoke() and a of set(), and/or (2) the downcast on the result of the call, such as (A) at invoke() and get().

Example 4.1**.**

Let us illustrate Target Inference by considering r = (A) $\mathcal{F}$.get(o) in Figure 15. If a target field name is known but its target class type (i.e., red circle) is missing, we can infer it from the types of all pointed-to objects $o^{\prime}$ by o. If $B$ is one such a type, then a potential target class of o is $B$ or any of its supertypes. If the target class type of $\mathcal{F}$ is $B$ but a potential target field name (i.e., blue circle) is missing, we can deduce it from the downcast (A) to resolve the call to r = o.f, where f is a member field in $B$ whose type is A or a supertype or subtype of A. A supertype is possible because a field of this supertype may initially point to an object of type A or a subtype of A.

In Figure 15, if getMethods() (getFields()) is called as a member-introspecting method instead, then an array of Method (Field) objects will be returned so that Target Propagation from it is implicitly performed by pointer analysis. All the other methods in Class for introspecting methods/fields/constructors are handled similarly.

Resolution Principles

To balance soundness, precision and scalability in a disciplined manner, collective inference resolves the targets at a side-effect method call site (Figure 15) if and only if one of the following three conditions is met:

• •

Both its target class type (red circle) and target member name (blue circle) are made available by target propagation (solid arrow) or target inference (dashed arrow).

• •

Only its target class type (red circle) is made available by target propagation (solid arrow) or target inference (dashed arrow).

• •

Only its target member name (blue circle) is made available by both target propagation (solid arrow) and target inference (dashed arrow).

In practice, the first condition is met by many calls to invoke(), get() and set(). In this case, the number of spurious targets introduced can be significantly reduced due to the simultaneous enforcement of two constraints (the red and blue circles).

To increase the inference power of Solar, as explained in Section 3.1, we will also resolve a side-effect call under the one of the other two conditions (i.e., when only one circle is available). The second condition requires only its target class type to be inferable, as a class (type) name that is prefixed with its package name is usually unique. However, when only its target member name (blue circle) is inferable, we insist both its name (solid arrow) and its descriptor (dashed arrow) are available. In a large program, many unrelated classes may happen to use the same method name. Just relying only the name of a method lone in the last condition may cause imprecision.

If a side-effect call does not satisfy any of the above three conditions, then Solar will flag it as being unsoundly resolved, as described in Section 4.4.

4.3 Lazy Heap Modeling

As shown in Section 2.3.3, reflective object creation, i.e., newInstance() is the most widely used side-effect method. Lazy heap modeling (LHM), illustrated in Figure 16, is developed to facilitate its target inference and the soundness reasoning for Solar.

There are three cases. Let us consider Cases (II) and (III) first. Usually, an object, say o, created by newInstance() will be used later either regularly or reflectively as shown in Cases (II) and (III), respectively. In Case (II), since the declared type of o is java.lang.Object, $o$ is first cast to a specific type before used for calling methods or accessing fields as a regular object. Thus, o will flow to some cast operations. In Case (III), o is used in a reflective way, i.e., as the first argument of a call to a side-effect method, invoke(), get() or set(), on which the target method (field) is called (accessed). This appears to be especially commonly used in Android apps.

For these two cases, we can leverage the information at o's usage sites to infer its type lazily and also make its corresponding effects (on static analysis) visible there. As for the (regular) side-effects that may be made by o along the paths from newInstance() call site to its usages sites, we use Case (I) to cover this situation.

Now, we examine these Cases (I) – (III), which are highlighted in Figure 16, one by one, in more detail. If cName at c = Class.forName(cName) is unknown, Solar will create a Class object cu that represents this unknown class and assign it to c. On discovering that c1 points to a cu at an allocation site i (v = c1.newInstance()), Solar will create an abstract object o${}^{u}_{\tt i}$ of an unknown type for the site to mark it as being unresolved yet. Subsequently, o${}^{u}_{\tt i}$ will flow into Cases (I) – (III).

In Case (I), the returned type of o${}^{u}_{\tt i}$ is declared as java.lang.Object. Before o${}^{u}_{\tt i}$ flows to a cast operation, the only side-effect that can be made by this object is to call some methods declared in java.lang.Object. In terms of reflection analysis, only the two pointer-affecting methods shown in Figure 16 need to be considered. Solar handles both soundly, by returning (1) an unknown string for v1.toString() and (2) an unknown Class object for v1.getClass(). Note that clone() cannot be called on v1 of type java.lang.Object (without a downcast being performed on v1 first).

Let us consider Cases (II) and (III), where each statement, say $S_{x}$, is called an LHM point, containing a variable $x$ into which o${}^{u}_{\tt i}$ flows. In Figure 16, we have $x\in\{\texttt{v2},\texttt{v3},\texttt{v4}\}$. Let lhm$(S_{x})$ be the set of class types discovered for the unknown class $u$ at $S_{x}$ by inferring from the cast operation at $S_{x}$ as in Case (II) or the information available at a call to (C) m1.invoke(v4, args) (e.g., on C, m1 and args) as in Case (III). For example, given S2v2: A a = (A) v2, lhm(S2v2) contains A and its subtypes. To account for the side-effects of v = c1.newInstance() at $S_{x}$ lazily, we add (conceptually) a statement, x = new T(), for every $T\in{\it lhm}(S_{x})$, before $S_{x}$. Thus, o${}^{u}_{\tt i}$ is finally split into and thus aliased with $n$ distinct abstract objects, o${}_{\tt i}^{T_{1}}$,…, o${}_{\tt i}^{T_{n}}$, where ${\it lhm}(S_{x})=\{T_{1},\dots,T_{n}\}$, such that $x$ will be made to point to all these new abstract objects.

Figure 16 illustrates lazy heap modeling for the case when neither A nor B has subtypes and the declaring class for m1 is discovered to be D, which has one subtype B. Thus, Solar will deduce that ${\it lhm}(\tt S2_{\tt v2})=\{\texttt{A}\}$, ${\it lhm}(\tt S3_{\tt v3})=\{\texttt{B}\}$ and ${\it lhm}(\tt S4_{\tt v4})=\{\texttt{B,D}\}$. Note that in Case (II), o${}^{u}_{\tt i}$ will not flow to a and b due to the cast operations.

As java.lang.Object contains no fields, all field accesses to o${}^{u}_{\tt i}$ will only be made on its lazily created objects. Therefore, if the same concrete object represented by o${}^{u}_{\tt i}$ flows to both $S_{x_{1}}$ and $S_{x_{2}}$, then ${\it lhm}(S_{x_{1}})\cap{\it lhm}(S_{x_{2}})\neq\emptyset$. This implies that $x_{1}$ and $x_{2}$ will point to a common object lazily created. For example, in Figure 16, v3 and v4 points to $o_{\tt i}^{\tt B}$ since ${\it lhm}(S3_{\tt v3})\cap{\it lhm}(S4_{\tt v4})=\{{\tt o}^{\tt B}_{\tt i}\}$. As a result, the alias relation between $x_{1}.f$ and $x_{2}.f$ is correctly maintained, where $f$ is a field of o${}^{u}_{\tt i}$.

Example 4.2**.**

In Figure 17, Solar will model the newInstance() call in line 3 lazily (as cName1 is statically unknown) by returning an object $o_{3}^{u}$ of an unknown type $u$. Note that $o_{3}^{u}$ flows into two kinds of usage points: the cast operation in line 12 and the invoke() call in line 15. In the former case, Solar will infer $u$ to be A and its subtypes in line 12. In the latter case, Solar will infer $u$ based on the information available in line 15 by distinguishing three cases. (1) If cName2 is known, then Solar deduces $u$ from the known class in cName2. (2) If cName2 is unknown but mName2 is known, then Solar deduces $u$ from the known method name in mName2 and the second argument new Object[] {b,c} of the invoke() call site. (3) If both cName2 and mName2 are unknown (given that the types of $o_{3}^{u}$ are already unknown), then Solar will flag the invoke() call in line 15 as being unsoundly resolved, detected automatically by verifying one of the soundness criteria, i.e., Condition (4) in Section 5.5.

Discussion

Under Assumption 4, we need only to handle the three cases in Figure 16 in order to establish whether a newInstance() call has been modeled soundly or not. The rare exception (which breaks Assumption 4) is that o${}^{u}_{\tt i}$ is created but never used later (where no hints are available). To achieve soundness in this rare case, the corresponding constructor (of the dynamic type of o${}^{u}_{\tt i}$) must be annotated to be analyzed statically unless ignoring it will not affect the points-to information to be obtained. Again, as validated in Section 7.2, Assumption 4 is found to be very practical.

4.4 Unsound Call Identification

Intuitively, we mark a side-effect reflective call as being unsoundly resolved when Solar has exhausted all its inference strategies to resolve it, but to no avail. In addition to Case (3) in Example 4.2, let us consider another case in Figure 16, except that c2 and mName are assumed to be unknown. Then m1 at s4: m1.invoke(v4, args) will be unknown. Solar will mark it as unsoundly resolved, since just leveraging args alone to infer its target methods may cause Solar to be too imprecise to scale (Section 4.2).

The formal soundness criteria that are used to identify unsoundly resolved reflective calls are defined and illustrated in Section 5.5.

4.5 Guided Lightweight Annotation

As shown in Example 3.1, Solar can guide users to the program points where hints for annotations are potentially available for unsoundly or imprecisely resolved reflective calls. As these problematic'' call sites are the places in a program where side-effect methods are invoked, we can hardly extract the information there to know the names of the reflective targets, as they are specified at the corresponding entry and member-introspecting call sites (also called the annotation sites), which may not appear in the same method or class (as the problematic call sites''). Thus, Solar is designed to automatically track the flows of metaobjects from the identified ``problematic'' call sites in a demand-driven way to locate all the related annotation sites.

In Solar, we propose to add annotations for unsoundly resolved side-effect call sites, which are often identified accurately. As a result, the number of required annotations (for achieving soundness) would be significantly less than that required in [Livshits et al. (2005)], which simply asks for annotations when the string argument of a reflective call is statically unknown. This is further validated in Section 7.3.

5 Formalism

We formalize Solar, as illustrated in Figure 13, for RefJava, which is Java restricted to a core subset of its reflection API. Solar is flow-insensitive but context-sensitive. However, our formalization is context-insensitive for simplicity. We first define RefJava (Section 5.1), give a road map for the formalism (Section 5.2) and present some notations used (Section 5.3). We then introduce a set of rules for formulating collective inference and lazy heap modeling in Solar's inference engine (Section 5.4). Based on these rules, we formulate a set of soundness criteria (Section 5.5) that enables reasoning about the soundness of Solar (Section 5.6). Finally, we describe how to instantiate Probe from Solar (Section 5.7), and handle static class members (Section 5.8).

5.1 The RefJava Language

RefJava consists of all Java programs (under Assumptions 1 – 4) except that the Java reflection API is restricted to the seven core reflection methods: one entry method Class.forName(), two member-introspecting methods getMethod() and getField(), and four side-effect methods for reflective object creation newInstance(), reflective method invocation invoke(), reflective fields access get() and modification set().

Our formalism is designed to allow its straightforward generalization to the entire Java reflection API. As is standard, a Java program is represented only by five kinds of statements in the SSA form, as shown in Figure 20. For simplicity, we assume that all the members (fields or methods) of a class accessed reflectively are its instance members, i.e., $\texttt{o}\neq\texttt{null}$ in get(o), set(o,a) and invoke(o,…) in Figure 15. We will formalize how to handle static members in Section 5.8.

5.2 Road Map

As depicted in Figure 18, Solar's inference engine, which consists of five components, works together with a pointer analysis. The arrow $\longleftrightarrow$ between a component and the pointer analysis means that each is both a producer and consumer of the other.

Let us take an example to see how this road map works. Consider the side-effect call t = f1.get(o) in Figure 15. If cName and fName are string constants, Propagation will create a Field object (pointed to by f1) carrying its known class and field information and pass it to Target Search ( 1 ). If cName or fName is not a constant, a Field object marked as such is created and passed to Inference ( 2 ), which will infer the missing information and pass a freshly generated Field object enriched with the missing information to Target Search ( 3 ). Then Target Search maps a Field object to its reflective target $f$ in its declaring class ( 4 ). Finally, Transformation turns the reflective call t = f1.get(o) into a regular statement t = o.$f$ and pass it to the pointer analysis ( 5 ). Note that Lazy Heap Modeling handles newInstance() based on the information discovered by Propagation ( a ) or Inference ( b ).

5.3 Notations

In this paper, a field signature consists of the field name and descriptor (i.e., field type), and a field is specified by its field signature and the class where it is defined (declared or inherited). Similarly, a method signature consists of the method name and descriptor (i.e., return type and parameter types) and, a method is specified by its method signature and the class where it is defined.

We will use the notations given in Figure 19. $\mathbb{CO}$, $\mathbb{FO}$ and $\mathbb{MO}$ represent the set of Class, Field and Method objects, respectively. In particular, $\texttt{c}^{t}$ denotes a Class object of a known class $t$ and $\texttt{c}^{u}$ denotes a Class object of an unknown class $u$. As illustrated in Figure 16, we write $o_{i}^{t}$ to represent an abstract object created at an allocation site $i$ if it is an instance of a known class $t$ and $o_{i}^{u}$ of (an unknown class type) otherwise. For a Field object, we write $\texttt{f}^{t}_{s}$ if it is a field defined in a known class $t$ and $\texttt{f}^{u}_{s}$ otherwise, with its signature being $s$. In particular, we write $\texttt{f}^{\,\_}_{u}$ for $\texttt{f}^{\,\_}_{s}$ in the special case when $s$ is unknown, i.e., $s.t_{f}=s.n_{f}=u$. Similarly, $\texttt{m}^{t}_{s}$, $\texttt{m}^{t}_{u}$, $\texttt{m}^{u}_{s}$ and $\texttt{m}^{u}_{u}$ are used to represent Method objects. We write $\texttt{m}^{\,\_}_{u}$ for $\texttt{m}^{\,\_}_{s}$ when $s$ is unknown (with the return type $s.t_{r}$ being irrelevant, i.e., either known or unknown), i.e., $s.n_{m}=s.p=u$.

5.4 The Inference Engine of Solar

We present the inference rules used by all the components in Figure 18, starting with the pointer analysis and moving to the five components of Solar. Due to their cyclic dependencies, the reader is invited to read ahead sometimes, particularly to Section 5.4.6 on LHM, before returning back to the current topic.

5.4.1 Pointer Analysis

Figure 20 gives a standard formulation of a flow-insensitive Andersen's pointer analysis for RefJava. pt(x) represents the points-to set of a pointer x. An array object is analyzed with its elements collapsed to a single field, denoted $arr$. For example, x[i] = y can be seen as x.$arr$ = y. In [A-New], $o_{i}^{t}$ uniquely identifies the abstract object created as an instance of $t$ at this allocation site, labeled by i. In [A-Ld] and [A-St], only the fields of an abstract object $o_{i}^{t}$ of a known type $t$ can be accessed. In Java, as explained in Section 4.3, the field accesses to $o_{i}^{u}$ (of an unknown type) can only be made to the abstract objects of known types created lazily from $o_{i}^{u}$ at LHM points.

In [A-Call] (for non-reflective calls), like the one presented in [Sridharan et al. (2013)], the function $dispatch(o_{i}^{\,\_},m)$ is used to resolve the virtual dispatch of method $m$ on the receiver object $o_{i}^{\,\_}$ to be $m^{\prime}$. There are two cases. If $o_{i}^{t}\in pt(y)$, we proceed normally as before. For $o_{i}^{u}\in pt(y)$, it suffices to restrict $m$ to $\{\texttt{toString()},\texttt{getClass()}\}$, as illustrated in Figure 16 and explained in Section 4.3. We assume that $m^{\prime}$ has a formal parameter $m_{this}^{\prime}$ for the receiver object and $m_{p1}^{\prime},\dots,m_{pn}^{\prime}$ for the remaining parameters, and a pseudo-variable $m_{ret}^{\prime}$ is used to hold the return value of $m^{\prime}$.

5.4.2 Propagation

Figure 21 gives the rules for handling forName(), getMethod() and getField() calls. Different kinds of Class, Method and Field objects are created depending on whether their string arguments are string constants or not. For these rules, $\mathbb{SC}$ denotes a set of string constants and the function $toClass$ creates a Class object $c^{t}$, where $t$ is the class specified by the string value returned by $val$($o_{i}$) (with $val:\mathbb{H}\rightarrow\texttt{java.lang.String}$).

By design, $\texttt{c}^{t}$, $\texttt{f}^{t}_{s}$ and $\texttt{m}^{t}_{s}$ will flow to Target Search but all the others, i.e., $\texttt{c}^{u}$, $\texttt{f}^{u}_{\,\_}$, $\texttt{f}^{\,\_}_{u}$, $\texttt{m}^{u}_{\,\_}$ and $\texttt{m}^{\,\_}_{u}$ will flow to Inference, where the missing information is inferred. During Propagation, only the name of a method/field signature $s$ ($s.n_{m}$ or $s.n_{f}$) can be discovered but its other parts are unknown: $s.t_{r}=s.p=s.t_{f}=u$.

5.4.3 Collective Inference

Figure 22 gives nine rules to infer reflective targets at x = (A) m.invoke(y,args), x = (A) f.get(y), f.set(y,x), where A indicates a post-dominating cast on their results. If A = Object, then no such cast exists. These rules fall into three categories. In [I-InvTp], [I-GetTp] and [I-SetTp], we use the types of the objects pointed to by y to infer the class type of a method/field. In [I-InvSig], [I-GetSig] and [I-SetSig], we use the information available at a call site (excluding y) to infer the descriptor of a method/field signature. In [I-InvS2T], [I-GetS2T] and [I-SetS2T], we use a method/field signature to infer the class type of a method/field.

Some notations used are in order. As is standard, $t<:t^{\prime}$ holds when $t$ is $t^{\prime}$ or a subtype of $t^{\prime}$. In [I-InvSig], [I-GetSig], [I-InvS2T] and [I-GetS2T], $\ll:$ is used to take advantage of the post-dominating cast (A) during inference when A is not Object. By definition, $u\ll:\tt Object$ holds. If $t^{\prime}$ is not Object, then $t\ll:t^{\prime}$ holds if and only if $t<:t^{\prime}$ or $t^{\prime}<:t$ holds. In [I-InvSig] and [I-InvS2T], the information on args is also exploited, where args is an array of type Object[], only when it can be analyzed exactly element-wise by an intra-procedural analysis. In this case, suppose that args is an array of $n$ elements. Let $A_{i}$ be the set of types of the objects pointed to by its $i$-th element, args[$i$]. Let $P_{i}=\{t^{\prime}\mid t\in A_{i},t<:t^{\prime}\}$. Then $Ptp(\texttt{args})=P_{0}\times\cdots\times P_{n-1}$. Otherwise, $Ptp(\texttt{args})=\varnothing$, implying that args is ignored as it cannot be exploited effectively during inference.

To maintain precision in [I-InvS2T], [I-GetS2T] and [I-SetS2T], we use a method (field) signature to infer its classes when both its name and descriptor are known. In [I-InvS2T], the function ${\cal M}(s_{t_{r}},s.{n_{m}},s.p)$ returns the set of classes where the method with the specified signature $s$ is defined if $s.n_{m}\neq u$ and $s.p\neq u$, and $\varnothing$ otherwise. The return type of the matching method is ignored if $s.{t_{r}}=u$. In [I-GetS2T] and [I-SetS2T], ${\cal F}(s.n_{f},s.t_{f})$ returns the set of classes where the field with the given signature $s$ is defined if $s.n_{f}\neq u$ and $s.t_{f}\neq u$, and $\varnothing$ otherwise.

Let us illustrate our rules by considering two examples in Figures 17 and 23.

Example 5.1**.**

Let us modify the reflective allocation site in line 3 (Figure 17) to c1.newInstance(), where c1 represents a known class, named A, so that $\texttt{c1}^{\texttt{A}}\in pt(\texttt{c1})$. By applying [L-KwTp] (introduced later in Figure 25) to the modified allocation site, Solar will create a new object $o_{3}^{\tt A}$, which will flow to line 10, so that $o_{3}^{\tt A}\in pt(\texttt{v})$. Suppose both cName2 and mName2 point to some unknown strings. When [P-GetMtd] is applied to c.getMethod(mName,…) in line 7, a Method object, say, $\texttt{m}_{u}^{u}$ is created and eventually assigned to m in line 14. By applying [I-InvTp] to m.invoke(v, args) in line 15, where $o_{3}^{\tt A}\in pt(v)$, Solar deduces that the target method is a member of class A. Thus, a new object $\texttt{m}^{\tt A}_{u}$ is created and assigned to $pt(\texttt{m})$. Given args = new Object[] {b, c}, $Ptp(args)$ is constructed as described earlier. By applying [I-InvSig] to this invoke() call, Solar will add all new Method objects $\texttt{m}^{\tt A}_{s}$ to $pt(\texttt{m})$ such that $s.p\in Ptp(args)$, which represent the potential target methods called reflectively at this site. ∎

Example 5.2**.**

In Figure 23, hd is statically unknown but the string argument of getMethod() is "handle", a string constant. By applying [P-ForName], [P-GetMtd] and [L-UkwTp] (Figure 25) to the forName(), getMethod() and newInstance() calls, respectively, we obtain $\texttt{c}^{u}\in pt(\texttt{c})$, $\texttt{m}^{u}_{s}\in pt(\texttt{m})$ and $o_{i}^{u}\in pt(\texttt{h})$, where $s$ indicates a signature with a known method name (i.e., ``handle''). Since the second argument of the invoke() call can also be exactly analyzed, Solar will be able to infer the classes $t$ where method "handle" is defined by applying [I-InvS2T]. Finally, Solar will add all inferred Method objects m${}^{t}_{s}$ to $pt(\texttt{m})$ at the invoke() call site. Since neither the superscript nor the subscript of m${}^{t}_{s}$ is u, the inference is finished and the inferred m${}^{t}_{s}$ will be used to find out the reflective targets (represented by it) in Target Search (Section 5.4.4). ∎

5.4.4 Target Search

For a Method object $\texttt{m}_{s}^{t}$ in a known class $t$ (with $s$ being possibly $u$), we define $MTD:\mathbb{MO}\rightarrow\mathcal{P}(\mathbb{M})$ to find all the methods matched:

[TABLE]

where $mtdLookUp$ is the standard lookup function for finding the methods according to a declaring class $t^{\prime}$ and a signature $s$ except that (1) the return type $s.t_{r}$ is also considered in the search (for better precision) and (2) any $u$ that appears in $s$ is treated as a wild card during the search.

Similarly, we define $FLD:\mathbb{FO}\!\rightarrow\!\mathcal{P}(\mathbb{F})$ for a Field object $\texttt{f}_{s}^{t}$:

[TABLE]

to find all the fields matched, where $fldLookUp$ plays a similar role as $mtdLookUp$. Note that both $MTD(\texttt{m}^{t}_{s})$ and $FLD(\texttt{f}^{t}_{s})$ also need to consider the super types of $t$ (i.e., the union of the results for all $t^{\prime}$ where $t<:t^{\prime}$, as shown in the functions) to be conservative due to the existence of member inheritance in Java.

5.4.5 Transformation

Figure 24 gives the rules used for transforming a reflective call into a regular statement, which will be analyzed by the pointer analysis.

Let us examine [T-Inv] in more detail. The second argument args points to a one-dimensional array of type Object[], with its elements collapsed to a single field $arr$ during the pointer analysis, unless args can be analyzed exactly intra-procedurally in our current implementation. Let arg1,…, argn be the $n$ freshly created arguments to be passed to each potential target method $m^{\prime}$ found by Target Search. Let $m_{p1}^{\prime},\dots,m_{pn}^{\prime}$ be the $n$ parameters (excluding $this$) of $m^{\prime}$, such that the declaring type of $m_{pk}^{\prime}$ is $t^{\prime\prime}$. We include $o_{j}^{t^{\prime}}$ to $pt({\tt arg}_{k})$ only when $t^{\prime}<:t^{\prime\prime}$ holds in order to filter out the objects that cannot be assigned to $m_{pk}^{\prime}$. Finally, the reflective target method found can be analyzed by [A-Call] in Figure 20.

5.4.6 Lazy Heap Modeling

In Figure 25, we give the rules for lazily resolving a newInstance() call, as explained in Section 4.3.

In [L-KwTp], for each Class object $\texttt{c}^{t}$ pointed to by c*′, an object, $o_{i}^{t}$, is created as an instance of this known type at allocation site $i$ straightaway. In [L-UkwTp], as illustrated in Figure 16, $o_{i}^{u}$ is created to enable LHM if c′* points to a $\texttt{c}^{u}$ instead. Then its lazy object creation happens at its Case (II) by applying [L-Cast] (with $o_{i}^{u}$ blocked from flowing from x to a) and its Case (III) by applying [L-Inv] and [L-GSet]. Note that in [L-Cast], A is assumed not to be Object.

5.5 Soundness Criteria

RefJava consists of four side-effect methods as described in Section 5.1. Solar is sound if their calls are resolved soundly under Assumptions 1 – 4. Due to Assumption 4 illustrated in Figure 16, there is no need to consider newInstance() since it is soundly resolved if invoke(), get() and set() are. For convenience, we define:

[TABLE]

which means that the dynamic type of every object pointed to by $v$ is known.

Recall the nine rules given for resolving (A) m.invoke(y, args), (A) f.get(y) and f.set(y, x) in Figure 22. For the Method (Field) objects $\texttt{m}_{s}^{t}$ ($\texttt{f}_{s}^{t}$) with known classes $t$, these targets can be soundly resolved by Target Search, except that the signatures $s$ can be further refined by applying [I-InvSig], [I-GetSig] and [I-SetSig].

For the Method (Field) objects $\texttt{m}_{s}^{u}$ ($\texttt{f}_{s}^{u}$) with unknown class types $u$, the targets accessed are inferred by applying the remaining six rules in Figure 22. Let us consider a call to (A) m.invoke(y, args). Solar attempts to infer the missing classes of its Method objects in two ways, by applying [I-InvTp] and [I-InvS2T]. Such a call is soundly resolved if the following condition holds:

[TABLE]

If the first disjunct holds, applying [I-InvTp] to invoke() can over-approximate its target methods from the types of all objects pointed to by y. Thus, every Method object $\texttt{m}_{\,\_}^{u}\in pt(m)$ is refined into a new one $\texttt{m}_{\,\_}^{t}$ for every $o_{i}^{t}\in pt(\texttt{y})$.

If the second disjunct holds, then [I-InvS2T] comes into play. Its targets are over-approximated based on the known method names $s.n_{m}$ and the types of the objects pointed to by args. Thus, every Method object $\texttt{m}_{s}^{u}\in pt(m)$ is refined into a new one $\texttt{m}_{s}^{t}$, where $s.t_{r}\ll:A$ and $s.p\in Ptp(\texttt{args})\neq\varnothing$. Note that $s.t_{r}$ is leveraged only when it is not $u$. The post-dominating cast (A) is considered not to exist if A = Object. In this case, $u\ll:\tt Object$ holds (only for $u$).

Finally, the soundness criteria for get() and set() are derived similarly:

[TABLE]

[TABLE]

In (5), applying [I-GetTp] ([I-GetS2T]) resolves a get() call soundly if its first (second) disjunct holds. In (6), applying [I-SetTp] ([I-SetS2T]) resolves a set() call soundly if its first (second) disjunct holds. By observing [T-Set], we see why $AllKwn(\texttt{x})$ is needed to reason about the soundness of [I-SetS2T].

5.6 Soundness Proof

We prove the soundness of Solar for RefJava subject to our soundness criteria (4) – (6) under Assumptions 1 – 4. We do so by taking advantage of the well-established soundness of Andersen's pointer analysis (Figure 20) stated below.

Lemma 5.3**.**

Solar* is sound for RefJava with its reflection API ignored.*

If we know the class types of all targets accessed at a reflective call but possibly nothing about their signatures, Solar can over-approximate its target method/fields in Target Search. Hence, the following lemma holds.

Lemma 5.4**.**

Solar* is sound for RefJavac**, the set of all RefJava programs in which cName is a string constant in every Class.forName(cName) call.*

Proof 5.5** (Sketch).**

By [P-ForName], the Class objects at all Class.forName(cName) calls are created from known class types. By Lemma 5.3, this has four implications. (1) LHM is not needed. For the rules in Figure 25, only [L-KwTp] is relevant, enabling every c′.newInstance() call to be resolved soundly as a set of regular new t() calls, for all Class objects $\texttt{c}^{t}\in pt(\texttt{c}^{\prime})$. (2) In [P-GetMtd], the Method objects m${}^{t}_{\,\_}$ of all class types $t$ accessed at a getMethod() call are created, where $\texttt{m}^{t}_{\,\_}$ symbolizes over-approximately all target methods in $MTD(\texttt{m}^{t}_{\,\_})$. The same sound approximation for getField() is made by [P-GetFld]. (3) For the nine rules given in Figure 22, only [I-InvSig], [I-GetSig] and [I-SetSig] are applicable, since $\nexists\texttt{m}_{\,\_}^{u}\in\texttt{m}$, $\nexists\texttt{f}_{\,\_}^{u}\in\texttt{f}$ and $\nexists o_{i}^{u}\in\texttt{y}$, in order to further refine their underlying method or field signatures. (4) In Figure 24, the set of reflective targets at each call site is over-approximated. By applying Lemma 5.3 again and noting Assumptions 1 – 3, Solar is sound for RefJavac*.*

Solar is sound subject to (4) – (6) under Assumptions 1 – 4.

Theorem 5.6**.**

Solar* is sound for RefJava if $SC(c)$ holds at every reflective call $c$ of the form (A) m.invoke(y, args), (A) f.get(y) or f.set(y, x).*

Proof 5.7** (Sketch).**

For reasons of symmetry, we focus only on a call, $c$, to (A) m.invoke(y, args). $SC(c)$ is given in (4). If its first disjunct is true, then all abstract objects flowing into y are created either from known classes soundly by [L-Kwtp] or lazily from unknown classes as illustrated in Figure 16 by applying initially [L-UkwUp] and later [L-Cast] (for Case (II)) and [L-Inv] (for Case (III)), but soundly under Assumption 4. If its second disjunct is true, then Solar can always infer the missing class types $t$ in a Method object $\texttt{m}_{s}^{u}$ pointed to by $pt(\texttt{m})$ to over-approximate the set of its target methods as $MTD(\texttt{m}_{s}^{t})$. This takes us back to a situation equivalent to the one established in the proof of Lemma 5.4. Thus, Solar is sound for RefJava if $SC(c)$ holds at every reflective call $c$ of the form (A) m.invoke(y, args).

5.7 Probe

We instantiate Probe, as shown in Figure 13, from Solar as follows. To make Probe resolve reflection precisely, we refrain from performing Solar's LHM by retaining [L-UkwTp] but ignoring [L-Cast], [L-GSet] and [L-Inv] and abandon some of Solar's sophisticated inference rules by disabling [I-InvS2T], [I-GetS2T] and [I-SetS2T].

In Target Search, Probe will restrict itself to only Method objects $\texttt{m}^{t}_{s}$ and Field objects $\texttt{f}^{t}_{s}$, where the signature $s$ is at least partially known.

5.8 Static Class Members

To handle static class members, our rules can be simply modified. In Figure 22, y = null. [I-InvTp], [I-GetTp] and [I-SetTp] are not needed (by assuming $pt(\texttt{null})=\varnothing$). In the soundness criteria stated in (4) – (6), the first disjunct is removed in each case. [I-InvS2T], [I-GetS2T] and [I-SetS2T] are modified with $o^{u}_{i}\in pt(\texttt{y})$ being replaced by $\texttt{y}=\texttt{null}$. The rules in Figure 24 are modified to deal with static members. In Figure 25, [L-GSet] and [L-Inv] are no longer relevant. The other rules remain applicable. The static initializers for the classes in the closed world are analyzed. This can happen at, say loads/stores for static fields as is the standard but also when some classes are discovered in [P-ForName], [L-Cast], [L-GSet] and [L-Inv].

6 Implementation

Solar, as shown in Figure 18, works together with a pointer analysis. We have implemented Solar on top of Doop [Bravenboer and Smaragdakis (2009)], a state-of-the-art pointer analysis framework for Java. Solar is implemented in the Datalog language. Presently, Solar consists of 303 Datalog rules written in about 2800 lines of code.

We release Solar as an open-source tool at http://www.cse.unsw.edu.au/~corg/solar. Now Solar has been augmented to output its reflection analysis results with the format that is supported by Soot (a popular framework for analyzing Java and Android applications), which enables Soot's clients to use Solar's results directly.

Below we extend our formalism for RefJava to handle the other methods in the Java reflection API, divided into entry, member-introspecting and side-effect methods. For details, we refer to the open-source software of Solar.

Entry Methods

We divide the entry methods into six groups, depending how a Class object is obtained, by (1) using a special syntax (A.class), (2) calling Object.getClass(), (3) using a full-qualified string name (in Class.forName() and ClassLoader.loadClass()), (4) calling proxy API Proxy.getProxyClass(), (5) calling, e.g., Class.getComponentType(), on a metaobject, and (6) calling, e.g., sun.reflect.Reflection.getCallerClass() to introspect an execution context. According to Section 2.3.3, the last two are infrequently used. Our current implementation handles the entry methods in (1) – (4) plus Class.getComponentType() in (5) since the latter is used in array-related side-effect methods.

Member-Introspecting Methods

In addition to the two included in RefJava, there are ten more member-introspecting methods as given in Figure 3. To show how to handle the other ten methods based on our existing formalism (Section 5), we take getDeclaredMethod() and getMethods() as examples as the others can be dealt with similarly. For a Method object resolved to be m${}^{t}_{s}$ at a getDeclaredMethod() call by Propagation, the search for building $MTD(\texttt{m}^{t}_{s})$ is confined to class $t$ (the only change in the rules). Otherwise, the search is done as described in Section 5.4.4.

For ms = c${}^{\prime}\!$.getMethods(), which returns an array of Method objects, its analysis is similarly done as m = c${}^{\prime}\!$.getMethod(mName) in Figure 21. We first create a placeholder array object $\texttt{ms}_{ph}$ so that $\texttt{ms}_{ph}\in pt(\texttt{ms})$. As getMethods() is parameterless, we then insert a new Method object m${}^{t}_{u}$ (m${}^{u}_{u}$) into $pt(\texttt{ms}_{ph}.arr)$ for every $\texttt{c}^{t}$ ($\texttt{c}^{u}$) in $pt(\texttt{c}^{\prime})$. The underlying pointer analysis will take care of how eventually an element of such an array flows into, say m, in m.invoke(). Then the rules in Figure 22 are applicable.

Side-Effect Methods

In addition to the four in RefJava, the following four side-effect methods are also analyzed. Constructor.newInstance() is handled as Class.newInstance() except that its array argument is handled exactly as in invoke(). Its call sites are also modeled lazily. Array.newInstance(), Array.get() and Array.set() are handled as in Table 2.2.2. Presently, Solar does not handle Proxy.newProxyInstance() in its implementation. However, it can be analyzed according to its semantics as described in Section 2.2.2.

7 Evaluation

We evaluate Solar by comparing it (primarily) with two state-of-the-art reflection analyses for Java, Doopr [Smaragdakis et al. (2015)] and Elf [Li et al. (2014)]. In particular, our evaluation addresses the following research questions (RQs):

• •

RQ1. How well does Solar achieve full automation without any annotations?

• •

RQ2. How well does Solar reason about the soundness and identify the unsoundly or imprecisely resolved (or ``problematic'') reflective calls?

• •

RQ3. How well does Solar make the trade-offs among soundness, precision and scalability in terms of reflection analysis? In other words, can Solar resolve reflection more soundly than Doopr and Elf with acceptable precision and efficiency?

Below we describe our experimental setup, revisit our assumptions, and answer these RQs in the given order.

7.1 Experimental Setup

As all the three reflection analyses, Doopr, Elf and Solar, are implemented in Doop [Bravenboer and Smaragdakis (2009)] (a state-of-the-art pointer analysis framework for Java) and run with a pointer analysis, we compare them by running each together with the same context-sensitive pointer analysis option provided by Doop: selective-2-type-sensitive+heap [Kastrinis and Smaragdakis (2013)].

Doopr denotes the reflection analysis proposed in [Smaragdakis et al. (2015)] and all its provided reflection resolution options are turned on including -enable-reflection, -enable-reflection-substring-analysis, -enable-reflection-use-based-analysis and -enable-reflection-invent-unknown-objects, in the experiment. Elf (version 0.3) is the reflection analysis proposed in  [Li et al. (2014)] with its default setting.

We use the LogicBlox Datalog engine (v3.9.0) on a Xeon E5-2650 2GHz machine with 64GB of RAM. We consider 7 large DaCapo benchmarks (2006-10-MR2) and 4 real-world applications, avrora-1.7.115 (a simulator), checkstyle-4.4 (a checker), freecs-1.3.20111225 (a server) and findbugs-1.2.1 (a bug detector), under a large reflection-rich Java library, JDK 1.6.0_45. The other 4 small DaCapo benchmarks are excluded since reflection is much less used.

7.2 Assumptions

When analyzing the real code in the experiment, we accommodate Assumptions 1 – 4 as follows. For Assumption 1, we rely on Doop's pointer analysis to simulate the behaviors of Java native methods. Dynamic class loading is assumed to be resolved separately. To simulate its effect, we create a closed world for a program, by locating the classes referenced with Doop's fact generator and adding additional ones found through program runs under TamiFlex [Bodden et al. (2011)]. For the DaCapo benchmarks, their three standard inputs are used. For avrora and checkstyle, their default test cases are used. For findbugs, one Java program is developed as its input since no default ones are available. For freecs, a server requiring user interactions, we only initialize it as the input in order to ensure repeatability. For a class in the closed-world of a program, Solar analyzes its static initializer at the outset if it is dynamically loaded and proceeds as discussed in Section 5.8 otherwise.

Assumptions 2 and 3 are taken for granted.

As for Assumption 4, we validate it for all reflective allocation sites where $o_{i}^{u}$ is created in the application code of the 10 programs that can be analyzed scalably. This assumption is found to hold at 75% of these sites automatically by performing a simple intra-procedural analysis. We have inspected the remaining 25% interprocedurally and found only two violating sites (in eclipse and checkstyle), where $o_{i}^{u}$ is never used. In the other sites inspected, $o_{i}^{u}$ flows through only local variables with all the call-chain lengths being at most 2. This shows that Assumption 4 generally holds in practice.

7.3 RQ1: Automation and Annotations

Figure 26 compares Solar and other reflection analyses [Livshits et al. (2005), Li et al. (2014), Smaragdakis et al. (2015), Barros et al. (2015), Li et al. (2016), Zhang et al. (2017)] denoted by ``Others'' by the degree of automation achieved. For an analysis, this is measured by the number of annotations required in order to improve the soundness of the reflective calls identified to be potentially unsoundly resolved.

Solar analyzes 7 out of the 11 programs scalably with full automation. For hsqldb, xalan and checkstyle, Solar is unscalable (under 3 hours). With Probe, a total of 14 reflective calls are flagged as being potentially unsoundly/imprecisely resolved. After 7 annotations, 2 in hsqldb, 2 in xalan and 3 in checkstyle, Solar is scalable, as discussed in Section 7.4. However, Solar is unscalable (under 3 hours) for jython, an interpreter (from DaCapo) for Python in which the Java libraries and application code are invoked reflectively from the Python code. Neither are Doopr and Elf.

``Others'' cannot identify which reflective calls may be unsoundly resolved; however, they can improve their soundness by adopting an annotation approach suggested in [Livshits et al. (2005)]. Generally, this approach requires users to annotate the string arguments of calls to entry and member-introspecting methods if they are not string constant. To reduce the annotation effort, e.g., for a clz = Class.forName(cName) call with cName being an input string, this approach leverages the intra-procedural post-dominating cast on the result of a clz.newInstance() call to infer the types of clz.

As shown in Figure 26, ``Others'' will require a total of 338 annotations initially and possibly more in the subsequent iterations (when more code is discovered). As discussed in Section 3.2.1, Solar's annotation approach is also iterative. However, for these programs, Solar requires a total of 7 annotations in only one iteration.

Solar outperforms ``Others'' due to its powerful inference engine for performing reflection resolution and its effective mechanism in accurately identifying unsoundly resolved reflective calls as explained in Section 3.1.

7.4 RQ2: Automatically Identifying

``Problematic'' Reflective Calls

If Solar is scalable in analyzing a program with no unsoundly resolved calls reported, then Solar is sound for this program under Assumptions 1 – 4 (Theorem 5.6). Thus, as discussed in Section 7.3, Solar is sound (in this sense) for the seven Java programs scalably analyzed (under 3 hours) with full automation in our experiment.

Solar is unscalable for hsqldb, xalan and checkstyle (under 3 hours). Probe is then run to identify their ``problematic'' reflective calls, reporting 13 potentially unsoundly resolved calls: 1 in hsqldb, 12 in xalan and 0 in checkstyle. Their handling is all unsound by code inspection, demonstrating the effectiveness of Solar in accurately pinpointing a small number of right parts of the program to improve unsoundness.

In addition, we currently adopt a simple approach to alerting users for potentially imprecisely resolved reflective calls. Probe sorts all the newInstance() call sites according to the number of objects lazily created at the cast operations operating on the result of a newInstance() call (by [L-Cast]) in non-increasing order. In addition, Probe ranks the remaining reflective call sites (of other side-effect methods) according to the number of reflective targets resolved, also in non-increasing order.

By focusing on unsoundly and imprecisely resolved reflective calls as opposed to the unknown input strings (see Section 7.3), only lightweight annotations are needed as shown in Figure 26, with 2 hsqldb, 2 xalan and 3 in checkstyle as explained below.

Probing hsqldb

Earlier, Figure 14 shows the output automatically generated for hsqldb by Probe (highlighting which reflective calls are resolved unsoundly or imprecisely), together with the suggested annotation sites (as introduced in Section 4.5). In Figure 14, all the call sites to (invoke) the same method are numbered from 0.

The unsound list contains one invoke(), with its relevant code appearing in class org.hsqldb.Function as shown. After Probe has finished, mMethod in line 352 points to a Method object m${}^{u}_{u}$ that is initially created in line 179 and later flows into line 182, indicating that the class type of $\texttt{m}_{u}^{u}$ is unknown since cn in line 169 is unknown. By inspecting the code, we find that cn can only be java.lang.Math or org.hsqldb.Library, read from some hash maps or obtained by string manipulations and is annotated as:

org.hsqldb.Function.<init>/java.lang.Class.forName/0 java.lang.Math

org.hsqldb.Function.<init>/java.lang.Class.forName/0 org.hsqldb.Library

The imprecise list for hsqldb is divided into two sections. In ``newInstance (Type Casting)'', there are 10 listed cast operations $(T)$ reached by an $o_{i}^{u}$ object such that the number of types inferred from $T$ is larger than 10. The top cast java.io.Serializable has $1391$ subtypes and is marked to be reached by a newInstance() call site in java.io.ObjectStreamClass. However, this is a false positive for the harness used due to imprecision in pointer analysis. Thus, we have annotated its corresponding Class.forName() call site in method resolveClass of class java.io.ObjectInputStream to return nothing. With the two annotations, Solar terminates in 45 minutes with its unsound list being empty.

Probing xalan

Probe reports 12 unsoundly resolved invoke() call sites. All Method objects flowing into these call sites are created at two getMethods() call sites in class extensions.MethodResolver. By inspecting the code, we find that the string arguments for the two getMethods() calls and their corresponding entry methods are all read from a file with its name hard-wired as xmlspec.xsl. For this input file provided by DaCapo, these two calls are never executed and thus annotated to be disregarded. With these two annotations, Solar terminates in 28 minutes with its unsound list being empty.

Probing checkstyle

Probe reports no unsoundly resolved call. To see why Solar is unscalable, we examine one invoke() call in line 1773 of Figure 27 found automatically by Probe that stands out as being possibly imprecisely resolved.

There are 962 target methods inferred at this call site. Probe highlights its corresponding member-introspecting method clz.getMethods() (in line 1294) and its entry methods (with one of these being shown in line 926). Based on this, we find easily by code inspection that the target methods called reflectively at the invoke() call are the setters whose names share the prefix set''. As a result, the clz.getMethods() call is annotated to return 158 setX'' methods in all the subclasses of AutomaticBean.

In addition, the Method objects created at one getMethods() call and one getDeclaredMethods() call in class *.beanutils.MappedPropertyDescriptor$1 flow into the invoke() call in line 1773 as false positives due to imprecision in the pointer analysis. These Method objects have been annotated away.

After the three annotations, Solar is scalable, terminating in 38 minutes.

7.5 RQ3: Soundness, Precision and Efficiency

In this section, we first compare the soundness of Doopr, Elf and Solar and then compare their analysis precision and efficiency to see if Solar's precision and efficiency are still acceptable while being significantly more sound than the prior work.

7.5.1 Soundness

To compare the soundness of Doopr, Elf and Solar, it is the most relevant to compare their recall, measured by the number of true reflective targets discovered at reflective calls to side-effect methods that are dynamically executed under certain inputs. Unlike Doopr and Elf, Solar can automatically identify ``problematic'' reflective calls for lightweight annotations. To ensure a fair comparison, the three annotated programs shown in Figure 26 are used by all the three reflection analyses.

Recall

Table 7.5.1 compares the recall of Doopr, Elf and Solar. We use TamiFlex [Bodden et al. (2011)], a practical dynamic reflection analysis tool to find the targets accessed at reflective calls in our programs under the inputs described in Section 7.2. Of the three analyses compared, Solar is the only one to achieve total recall, for all reflective targets, including both methods and fields, accessed.

For each DaCapo benchmark, its main code body is run under a reflection-based harness. As a result, static analysis tools, including Doopr, Elf and Solar, use its xdeps version driven by a reflection-free harness. However, TamiFlex needs to run each DaCapo benchmark with the reflection-based harness dynamically. For each DaCapo benchmark, two harnesses lead to different versions used for a few classes (e.g., org.apache.xerces.parsers.SAXParser) in eclipse, fop, pmd and xalan. In Table 7.5.1, we thus ignore the totally 21 extra reflective targets accessed by TamiFlex.

In practice, a reflection analysis must handle newInstance() and invoke() well in order to build the call graph for a program. Let us see how resolving more (true) reflective targets in a program by Solar can affect the call graph of the program.

Call Graph

Figure 28 compares Doopr, Elf and Solar in terms of true caller-callee relations discovered. These numbers are statically calculated and obtained by an instrumental tool written on top of Javassist [Chiba (2000)]. According to Table 7.5.1, Solar recalls a total of 191% (148%) more targets than Doopr (Elf) at the calls to newInstance() and invoke(), translating into 44787 (40583) more true caller-callee relations found for the 10 programs under the inputs described in Section 7.2. These numbers are expected to improve when more inputs are used. Note that all method targets recalled by Doopr and Elf are recalled by Solar so that we can use the ``subtraction'' (i.e., Solar $-\,$Doopr and Solar $-\,$Elf) in Figure 28.

Let us examine eclipse and checkstyle. We start with eclipse. According to Table 7.5.1, Solar finds 35 more target methods than Doopr, causing 25177 more true caller-callee relations to be discovered. Due to LHM, Solar finds 13 more target methods at newInstance() calls than Elf, resulting in 20400 additional true caller-callee relations to be introduced. Let us consider now checkstyle. Due to collective inference, Solar has resolved 23 more target methods at invoke() calls than Elf, resulting in 2437 more true caller-callee relations (i.e., over a third of the total number of such relations, 6706) to be discovered.

7.5.2 Precision

Table 7.5.2 compares the analysis precision of Doopr, Elf and Solar with an important client, devirtualization, which is only applicable to virtual calls with one single target each. This client is critical in call graph construction and thus often used for measuring the precision of a pointer analysis. Despite achieving better recall (Table 7.5.1), which results in more true caller-callee relations to be discovered (Figure 28), Solar maintains a similar precision as Doopr and Elf for this client.

In Solar, its lazy heap modeling (LHM) relies on cast types (and their subtypes) to infer reflective targets. Will this inference strategy introduce too much imprecision into the analysis when a cast type has many subtypes? To address this concern, we conduct an experiment about the percentage distribution for the number of types inferred at cast-related LHM points. As shown in Figure 29, the number of inferred types in a program is 1 ($\leqslant\!10$) at 30.8% (85.4%) of its cast-related LHM points. Some types (e.g., java.io.Serializable) are quite wide, giving rise to more than 50 inferred types each, but rare, appearing at an average of about 1.9% cast-related LHM points in a program.

7.5.3 Efficiency

Table 7.5.2 compares the analysis times of Doopr, Elf and Solar. Despite producing significantly better soundness than Doopr and Elf, Solar is only several-fold slower. When analyzing hsqldb, xalan and checkstyle, Solar requires some lightweight annotations. Their analysis times are the ones consumed by Solar on analyzing the annotated programs. Note that these annotated programs are also used by Doopr and Elf (to ensure a fair comparison).

In summary, the experimental results described in Section 7.5 demonstrate that Solar's soundness-guided design is effective in balancing soundness, precision and scalability, in practice: Solar is able to achieve significantly better soundness than the state-of-the-art while being still reasonably precise and efficient.

8 Related Work

8.1 Static Reflection Analysis

\citeN

Livshits05 introduce the first static reflection analysis for Java. By interleaving with a pointer analysis, this reflection analysis discovers constant string values by performing regular string inference and infers the types of reflectively created objects at clz.newInstance() calls, where clz is unknown, by exploiting their intra-procedurally post-dominating cast operations, if any. Many modern pointer analysis frameworks such as Doop [Bravenboer and Smaragdakis (2009)], Wala [(57)] and Chord [Naik et al. (2006)], adopt a similar approach to analyze Java reflection, and many subsequent reflection analyses [Li et al. (2014), Li et al. (2015), Smaragdakis et al. (2015), Zhang et al. (2017)], including Solar, are also inspired by the same work.

Our Elf tool [Li et al. (2014)] represents the first reflection analysis that takes advantage of the self-inferencing property (Definition 2.4) to handle Java reflection. Elf can be considered as performing the collective inference in Solar's inference engine except that Elf's inference rules are more strict (for better analysis precision). In Elf, a reflective target will not be resolved unless both a red circle and a blue circle in Figure 15 (i.e., a class name and part of a member signature) are available. As a result, Elf is usually more precise and efficient, but (much) less sound than Solar.

In Doopr [Smaragdakis et al. (2015)] (the one compared with Solar in Section 7), the authors propose to leverage partial string information to resolve reflective targets. As explained in Section 2.3.3, many string arguments are generated through complex string manipulations, causing their values to be hard to resolve statically. However, in some cases, its substring analysis makes it possible to leverage some partially available string values, in the form of self-inferencing hints, to help infer reflective targets. Combining this with some sophisticated string analyses [Christensen et al. (2003)] is expected to generate more effective results, which is worth pursuing in future work.

To improve soundness, Doopr attempts to infer the class types at Class.forName() (rather than newInstance()) call sites by leveraging both (1) the intra- and inter-procedural cast operations that are not necessarily post-dominating at their corresponding newInstance() call sites and (2) the member names at their corresponding member-introspecting call sites (i.e., the blue circles formed by Target Propagation in Figure 15). However, these two strategies may make the analysis imprecise. For example, the second strategy may suffer from a precision loss when different unrelated classes contain identically-named members [Li et al. (2014)]. In addition, in both strategies (1) and (2), the class types (at a Class.forName() call site), which are back-propagated (inferred) from some member-introspecting call sites (cast sites), may further pollute the analysis precision at the other member-introspecting and side-effect calls. To reduce such imprecision, an approach called inventing objects is proposed in Doopr. It creates objects at the newInstance() call sites (according to the types at the related cast sites), rather than the corresponding Class.forName() call sites. This method is similar to Case (II) in Solar's lazy heap modeling (Figure 16).

\citeN

Ernst15 analyze Java reflection and intents in Android apps, by reasoning about soundness from the perspective of a given client. Consider a client for detecting sensitive data leaks. Any invoke() call that cannot be resolved soundly is assumed to return conservatively some sensitive data. While sound for the client, the reflection analysis itself is still unsound. In terms of reflection inference, \citeNErnst15 exploit only a subset of self-inferencing hints used in Solar. For example, how the arguments in an invoke() call are handled. \citeNErnst15 uses only their arity but ignore their types. In contrast, Solar takes both into account. There are precision implications. Consider the code fragment for Eclipse in Figure 10. If the types of the elements of its one-dimensional array, parameters, are ignored, many spurious target methods in line 175 would be inferred, as single-argument methods are common.

Despite recent advances on reflection analysis [Li et al. (2014), Li et al. (2015), Smaragdakis et al. (2015)], a sophisticated reflection analysis does not co-exist well with a sophisticated pointer analysis, since the latter is usually unscalable for large programs [Livshits et al. (2005), Li et al. (2014), Li et al. (2015), Smaragdakis et al. (2015)]. If a scalable but imprecise pointer analysis is used instead, the reflection analysis may introduce many spurious call graph edges, making its underlying client applications to be too imprecise to be practically useful. This problem can be alleviated by using a recently proposed program slicing approach, called program tailoring [Li et al. (2016)].

Briefly, program tailoring accepts a sequential criterion (e.g., a sequence of reflective call sites: forName()$\rightarrow$getMethod()$\rightarrow$invoke()) and generates a soundly tailored program that contains the statements only relevant to the given sequential criterion. In other words, the tailored program comprises the statements in all possible execution paths passing through the sequence in the given order. As a result, a more precise (but less scalable) pointer analysis may be scalable when the tailored program (with smaller size) is analyzed, resulting a more precise result resolved at the given reflective call site (e.g., the above invoke() call site). These reflective call sites can be the problematic ones generated by Solar as demonstrated in [Li et al. (2016)].

DroidRa [Li et al. (2016)] analyzes reflection in Android apps by propagating string constants. This is similar to the target propagation in Solar's collective inference except that DroidRa uses the solver Coal [Octeau et al. (2015)] to resolve the string values in a context- and flow-sensitive manner. Currently, Solar's target propagation is context-sensitive only, achieved by the underlying pointer analysis used.

Ripple [Zhang et al. (2017)] resolves reflection in Android apps by tackling their incomplete information environments (e.g., undetermined intents or unmodeled services). Technically, even if some data flows are missing (i.e, null), it is still able to resolve reflective targets by performing type inference, which is similar to Solar's collective inference except that some sophisticated inference rules are not supported.

Unlike the prior work [Livshits et al. (2005), Li et al. (2014), Smaragdakis et al. (2015), Barros et al. (2015), Li et al. (2016), Zhang et al. (2017)], as highlighted in Figure 1, Solar is capable of reasoning about its soundness and accurately identifying its unsoundness.

8.2 Dynamic Reflection Analysis

\citeN

Hirzel07 propose an online pointer analysis for handling some dynamic features in Java at run time. To tackle reflection, their analysis instruments a program so that constraints are generated dynamically when the injected code is triggered at run time. Thus, the points-to information is incrementally updated when new constraints are gradually introduced by reflection. This technique on reflection handling can be used in JIT optimizations but may not be suitable for whole-program static analysis.

To facilitate static analysis, \citeNBodden11 leverage the runtime information gathered at reflective calls. Their tool, TamiFlex, records usage information of reflective calls in the program at run-time, interprets the logging information, and finally, transforms these reflective calls into regular Java method calls. In addition, TamiFlex inserts runtime checks to warn the user in cases that the program encounters reflective calls that diverge from the recorded information of previous runs.

Harvester [Rasthofer et al. (2016)] is designed to automatically extract runtime values from Android applications. It uses a variation of traditional program slicing and dynamic execution to extract values from obfuscated malware samples that obfuscate method calls using reflection or hide sensitive values in native code.

8.3 Others

\citeN

Braux00 provide offline partial evaluation support for reflection in order to perform aggressive compiler optimizations for Java programs. It transforms a program by compiling away the reflection code into regular operations on objects according to their concrete types that are constrained manually. The inference engine of Solar can be viewed as a tool for inferring such constraints automatically.

To increase code coverage, some static analysis tools [Bravenboer and Smaragdakis (2009), Whaley and Lam (2004)] allow users to provide ad hoc manual specifications about reflection usage in a program. However, due to the diversity and complexity of applications, it is not yet clear how to do so in a systematic manner. For framework-based web applications, Sridharan et al. [Sridharan et al. (2011)] introduce a framework that exploits domain knowledge to automatically generate a specification of framework-related behaviours (e.g., reflection usage) by processing both application code and configuration files. Solar may also utilize domain knowledge to analyze some configuration files, but only for those reflective call sites that cannot be resolved effectively.

\citeN

Li17 propose an object-oriented dynamic symbolic execution framework for testing object-oriented libraries in Java. They support polymorphism by introducing constraints for method invocation targets and field manipulations via symbolic types. They have also generalized the notion of symbolic types to symbolic methods and symbolic fields to handle Java reflection symbolically.

Finally, the dynamic analyses [Bodden et al. (2011), Hirzel et al. (2007), Rasthofer et al. (2016)] work in the presence of both dynamic class loading and reflection. Nguyen and Xue [Nguyen and Xue (2005), Xue and Nguyen (2005)] introduce an inter-procedural side-effect analysis for open-world Java programs by allowing dynamic class loading but disallowing reflection. Like other static reflection analyses [Livshits et al. (2005), Li et al. (2014), Smaragdakis et al. (2015), Barros et al. (2015), Li et al. (2016), Zhang et al. (2017)], Solar can presently analyze closed-world Java programs only.

9 Conclusions

Reflection analysis is a long-standing hard open problem. In the past years, almost all the research papers consider Java reflection as a separate assumption and most static analysis tools either handle it partially or totally ignore it. In the program analysis community, people hold to the common opinion that ``reflection is a dynamic feature, so how could it be handled effectively in static analysis?'' This paper aims to change such informed opinion by showing that effective static analysis for handling Java reflection is feasible. We present a comprehensive understanding of Java reflection by illustrating its concept (origin), interface design and real-world usage. Many useful findings are given to guide the design of more effective reflection analysis approaches and tools. We introduce Solar, a soundness-guided reflection analysis, which is able to achieve significantly better soundness than previous work and can also accurately and automatically identify which reflective calls are resolved unsoundly or imprecisely. Such capabilities are helpful, in practice, as users can be aware of how sound an analysis is. In addition, for some clients where high-quality analysis results are needed (e.g., bug detectors with good precision or verification tools with good soundness) for a program, Solar provides an opportunity to help users obtain the analysis results as desired, by guiding them to add some lightweight annotations, if needed, to the parts of the program, where unsoundly or imprecisely resolved reflective calls are identified.