related reflective calls,and (N3)automatic identification of "problematic" reflective calls that may threaten its soundness,precision and scalability. -We formalize SoLAR as part of a pointer analysis for Java(including a small core of its reflection APl)and reason about its soundness under a set of assumptions(Section 3).We have produced an open source implementation on top of Doop [18,which is a modern pointer analysis tool for Java. We evaluate SOLAR against two state-of-the-art reflection analyses,Doop [5] and ELF [21],with 11 large Java benchmarks/applications (Section 4),where all the three are treated as under-approximate analyses(due to,e.g.,native code).By instrumenting these programs under their associated inputs(when available).SOLAR is the only one to achieve total recall(for all reflective tar- gets accessed),with 371%(148%)more target methods resolved than Doop (ELF)in total,which translates into 49700(40570)more true caller-callee re- lations statically calculated w.r.t.these inputs alone.SoLAR has done so by maintaining nearly the same precision as and running only several-fold more slowly than ELF and DooP,subject to only 7 annotations in 3 programs. 2 Methodology Fig.1 illustrates an example of reflection usage abstracted in real code.In line 2, a Class metaobject c1 is created by calling Class.forName(cName)to represent the class named cName,where cName,i.e.,cName1 in line 10 is an input string to be read from a command line or a configuration file.In line 3.an object o is refectively created as an instance of c1 by calling c1.newInstance()and then assigned to v with the declared type as Java.lang.Object in line 10. Subsequently,o is used in two common scenarios.In the if branch,o is downcast to a specific type,A,and then used appropriately.The else branch is more interesting.In line 14,a Method metaobject m is created by calling getMethod() indirectly in line 7,with its class name,method name and formal parameters specified by cName2,mName2 and "..."(elided)in line 7,respectively.In line 15, this method is called reflectively on the receiver object o(pointed to by v)with the actual argument being passed in an array,new object[]{x,y}. 1 Object createObj(String cName){ 9 void foo(xx.Yy....) Class c1=Class.forName(cName) 10 Object v=createObj(cName1)://cName1 is an input string retum c1.newinstance0: if(.)( 12 Aa=(A)v: 13 }else{ 5 Method getMtd(String cName.String mName){14 Method m=getMtd(cName2,mName2): 6 Class c2=Class.forName(cName): 5 m.invoke(v,new Object](x,y)): retum c2.getMethod(mName....) 16 8} 17} Fig.1.An example of reflection usage abstracted from JDK 1.6.0_45. A refection analysis infers,i.e..resolves statically the reflective targets ac- cessed at reflective call sites.As usual,soundnesss demands over-approximation. Reflection introduces many challenges for static analysis.First,a modern reflec- tion API is large and complex.Second,reflection is typically used as a meansrelated reflective calls, and (N3) automatic identification of “problematic” reflective calls that may threaten its soundness, precision and scalability. – We formalize Solar as part of a pointer analysis for Java (including a small core of its reflection API) and reason about its soundness under a set of assumptions (Section 3). We have produced an open source implementation on top of Doop [18], which is a modern pointer analysis tool for Java. – We evaluate Solar against two state-of-the-art reflection analyses, Doop [5] and Elf [21], with 11 large Java benchmarks/applications (Section 4), where all the three are treated as under-approximate analyses (due to, e.g., native code). By instrumenting these programs under their associated inputs (when available), Solar is the only one to achieve total recall (for all reflective tar￾gets accessed), with 371% (148%) more target methods resolved than Doop (Elf) in total, which translates into 49700 (40570) more true caller-callee re￾lations statically calculated w.r.t. these inputs alone. Solar has done so by maintaining nearly the same precision as and running only several-fold more slowly than Elf and Doop, subject to only 7 annotations in 3 programs. 2 Methodology Fig. 1 illustrates an example of reflection usage abstracted in real code. In line 2, a Class metaobject c1 is created by calling Class.forName(cName) to represent the class named cName, where cName, i.e., cName1 in line 10 is an input string to be read from a command line or a configuration file. In line 3, an object o is reflectively created as an instance of c1 by calling c1.newInstance() and then assigned to v with the declared type as Java.lang.Object in line 10. Subsequently, o is used in two common scenarios. In the if branch, o is downcast to a specific type, A, and then used appropriately. The else branch is more interesting. In line 14, a Method metaobject m is created by calling getMethod() indirectly in line 7, with its class name, method name and formal parameters specified by cName2, mName2 and “. . . ” (elided) in line 7, respectively. In line 15, this method is called reflectively on the receiver object o (pointed to by v) with the actual argument being passed in an array, new Object[] {x, y}. 1 Object createObj(String cName) { 2 Class c1 = Class.forName(cName); 3 return c1.newInstance(); 4 } 5 Method getMtd(String cName, String mName) { 6 Class c2 = Class.forName(cName); 7 return c2.getMethod(mName, ... ); 8 } 9 void foo(X x, Y y, … ) { 10 Object v = createObj(cName1); //cName1 is an input string 11 if ( … ) { 12 A a = (A) v; 13 } else { 14 Method m = getMtd(cName2, mName2); 15 m.invoke(v, new Object[] {x, y}); 16 } 17 } … … Fig. 1. An example of reflection usage abstracted from JDK 1.6.0 45. A reflection analysis infers, i.e., resolves statically the reflective targets ac￾cessed at reflective call sites. As usual, soundnesss demands over-approximation. Reflection introduces many challenges for static analysis. First, a modern reflec￾tion API is large and complex. Second, reflection is typically used as a means