7:2 Yue Li,Tian Tan,and Jingling Xue environment in a decoupled way.Due to such advantages,reflection has been widely used in a variety of Java applications and frameworks [32,69]. Static analysis is widely recognized as a fundamental tool for bug detection [17,43],security vulnerability analysis [1,36],compiler optimization [14,59],program verification [4,12],and program debugging and understanding [34,58].However,when applying static analysis to Java programs,reflection poses a major obstacle [32,33,38,51].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 [37].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 [37]: "Reflection usage and the size of libraries/frameworks make it very difficult to scale points-to analysis to modern Java programs."[64]; "Reflection makes it difficult to analyze statically."[48]; "In our experience [18],the largest challenge to analyzing Android apps is their use of reflection.”[2]: "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."[26]. 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 [32,33,38,50,51],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(Figure 5),resulting in limited soundness ACM Trans.Softw.Eng.Methodol.,Vol.28,No.2,Article 7.Publication date:February 2019.7:2 Yue Li, Tian Tan, and Jingling Xue environment in a decoupled way. Due to such advantages, reflection has been widely used in a variety of Java applications and frameworks [32, 69]. Static analysis is widely recognized as a fundamental tool for bug detection [17, 43], security vulnerability analysis [1, 36], compiler optimization [14, 59], program verification [4, 12], and program debugging and understanding [34, 58]. However, when applying static analysis to Java programs, reflection poses a major obstacle [32, 33, 38, 51]. 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 [37]. 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 [37]: “Reflection usage and the size of libraries/frameworks make it very difficult to scale points-to analysis to modern Java programs.” [64]; “Reflection makes it difficult to analyze statically.” [48]; “In our experience [18], the largest challenge to analyzing Android apps is their use of reflection ...” [2]; “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.” [26]. 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 [32, 33, 38, 50, 51], 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 (Figure 5), resulting in limited soundness ACM Trans. Softw. Eng. Methodol., Vol. 28, No. 2, Article 7. Publication date: February 2019