ignoring (L-CAsr]and [L-INv])and abandon some of SOLAR's sophisticated inference rules (by disabling [-INVS2T]).In Target Search,PROBE will restrict itself to only Method metaobjects m,where the signature s is at least partially known. 3.9 Static Class Members To handle static class members,our rules can be modified.In Fig.7,y null. [I-INVTP]is not needed (by assuming pt(null)=3).In (3),the first disjunct is removed.[I-Ixvs2T]is modified with oe pt(y)replaced by y null.The rules in Fig.8 are modified to deal with static members.In Fig.9,[L-INv]is no longer relevant.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]and [L-INv]. 4 Evaluation We have implemented SOLAR on top of Doop [18],a modern pointer analysis tool for Java.We compare SoLAR with two state-of-the-art under-approximate reflection analyses,ELF [21]and the reflection analysis provided in Doop (also referred to as Doop).In some programs,Assumptions 1-4 may not hold.Thus, SOLAR is also treated as being under-approximate.Due to its soundness-guided design,however,SOLAR can yield significantly better under-approximations than DoOp and ELF.Like DOoP and ELF.SOLAR is also implemented in the Datalog language.As far as we know,SOLAR is more comprehensive in handling the Java reflection API than the prior reflection analyses [2,5,17,18,20,21]. In particular,our evaluation addresses the following research questions(RQs): -RQ1.How well does SOLAR achieve full automation without using PROBE? -RQ2.How does SoLAR identify automatically "problematic"reflective calls affecting its soundness,precision and scalability,thereby facilitating their improvement by means of some lightweight annotations? RQ3.How significantly does SoLAR improve recall compared to Doop [18] and ELF [21],while maintaining nearly the same precision? RQ4.How does SOLAR scale in analysing large reflection-rich applications? 4.1 Experimental Setup The three reflection analyses are compared by running each together with the same Doop pointer analysis framework (using its stable version r160113)[18]. For the Doop framework,we did not use its beta release(r5459247).The beta release handles a larger part of the Java reflection API but discovers fewer reflec- tive targets in our recall experiment,since it ignores reflective targets whose class types are in the libraries(for efficiency reasons).All the three reflection analyses operate on the SSA form of a program emitted by SooT [19],context-sensitively under selective-2-type-sensitive+heap provided by Doop. We use the LogicBlox Datalog engine(v3.9.0)on a Xeon E5-2650 2GHz ma- chine 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 de- tector),under a large reflection-rich Java library,JDK 1.6.0_45.ignoring [L-Cast] and [L-Inv]) and abandon some of Solar’s sophisticated inference rules (by disabling [I-InvS2T]). In Target Search, Probe will restrict itself to only Method metaobjects m t s , where the signature s is at least partially known. 3.9 Static Class Members To handle static class members, our rules can be modified. In Fig. 7, y = null. [I-InvTp] is not needed (by assuming ptpnullq “ ∅). In (3), the first disjunct is removed. [I-InvS2T] is modified with o u i P ptpyq replaced by y “ null. The rules in Fig. 8 are modified to deal with static members. In Fig. 9, [L-Inv] is no longer relevant. 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] and [L-Inv]. 4 Evaluation We have implemented Solar on top of Doop [18], a modern pointer analysis tool for Java. We compare Solar with two state-of-the-art under-approximate reflection analyses, Elf [21] and the reflection analysis provided in Doop (also referred to as Doop). In some programs, Assumptions 1 – 4 may not hold. Thus, Solar is also treated as being under-approximate. Due to its soundness-guided design, however, Solar can yield significantly better under-approximations than Doop and Elf. Like Doop and Elf, Solar is also implemented in the Datalog language. As far as we know, Solar is more comprehensive in handling the Java reflection API than the prior reflection analyses [2, 5, 17, 18, 20, 21]. In particular, our evaluation addresses the following research questions (RQs): – RQ1. How well does Solar achieve full automation without using Probe? – RQ2. How does Solar identify automatically “problematic” reflective calls affecting its soundness, precision and scalability, thereby facilitating their improvement by means of some lightweight annotations? – RQ3. How significantly does Solar improve recall compared to Doop [18] and Elf [21], while maintaining nearly the same precision? – RQ4. How does Solar scale in analysing large reflection-rich applications? 4.1 Experimental Setup The three reflection analyses are compared by running each together with the same Doop pointer analysis framework (using its stable version r160113) [18]. For the Doop framework, we did not use its beta release (r5459247). The beta release handles a larger part of the Java reflection API but discovers fewer reflec￾tive targets in our recall experiment, since it ignores reflective targets whose class types are in the libraries (for efficiency reasons). All the three reflection analyses operate on the SSA form of a program emitted by Soot [19], context-sensitively under selective-2-type-sensitive+heap provided by Doop. We use the LogicBlox Datalog engine (v3.9.0) on a Xeon E5-2650 2GHz ma￾chine 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 de￾tector), under a large reflection-rich Java library, JDK 1.6.0 45