newInstance()call is ignored.Recently.in DoOP (r5459247-beta)18,the ob- jects created in line 10(or line 3)are assumed to be of type A by taking advantage of the non-post-dominating cast (A)in line 12 to analyze more code.However, the objects with other types created along both the if and else branches are ignored.In prior work,such under-approximate handling of newInstance()is a significant source of unsoundness,as a large part of the program called on the thus ignored objects has been rendered invisible for analysis. L2.Isolated Inferences Many reflective calls(e.g.,those in Fig.1)are related but analysed mostly in isolation,resulting in under-approximated behaviours.In [21],we presented a self-inferencing reflection analysis,called ELF,that can infer more targets at a reflective call site than before [5,17,18,20,22],by exploiting more information available(e.g.,from its arguments and return type).However, due to eager heap modeling,ELF will still ignore the invoke()call in line 15 as v points to objects of unknown types as discussed above. L3.Design-Time Soundness,Precision and Scalability When analysing a program heuristically,a best-effort approach does not know which reflective calls may potentially affect its soundness,precision and scalability.As a result, a developer is out of luck with a program if such best-effort analysis is either unscalable or scalable but with undesired soundness or precision or both. 2.3 SOLAR:Soundness-Guided Reflection Resolution Fig.2 illustrates the SoLAR design,with its three novel aspects marked by N1 -N3,where Ni is introduced to overcome the afore-mentioned limitation Li. Jave Scalable Satisfied Programs N1 Lazy Heap Modeling Prover N2 Collective inference Urscalable PROBE Lightweight Arnotations impreicse Unsound Reflective Cals Fig.2.SOLAR:a soundness-guided analysis with three novel aspects,N1-N3. N1.Lazy Heap Modeling (LHM)SOLAR handles reflective object creation lazily by delaying the creation of objects at their usage points where their types may be inferred,achieving significantly improved soundness and precision. Let us describe the basic idea behind using the example in Fig.1.As cName at c1 Class.forName(cName)in line 2 is unknown,SOLAR will create a Class metaobject ciu that represents this unknown class and assign it to c1.As ci points to c1"at the allocation site v=c1.newInstance()in line 3,SOLAR will create an abstract object o of an unknown type for the site to mark it as being unresolved yet.Subsequently,o will flow into two usage points:Case(I)a type cast operation in line 12 and Case (II)a reflective method call site in line 15. In Case (I),where o is downcast to A,its type u is inferred to be A or any of its subtypes.Let t1,...,tn be all the inferred types.Then o is split into nnewInstance() call is ignored. Recently, in Doop (r5459247-beta) [18], the ob￾jects created in line 10 (or line 3) are assumed to be of type A by taking advantage of the non-post-dominating cast (A) in line 12 to analyze more code. However, the objects with other types created along both the if and else branches are ignored. In prior work, such under-approximate handling of newInstance() is a significant source of unsoundness, as a large part of the program called on the thus ignored objects has been rendered invisible for analysis. L2. Isolated Inferences Many reflective calls (e.g., those in Fig. 1) are related but analysed mostly in isolation, resulting in under-approximated behaviours. In [21], we presented a self-inferencing reflection analysis, called Elf, that can infer more targets at a reflective call site than before [5, 17, 18, 20, 22], by exploiting more information available (e.g., from its arguments and return type). However, due to eager heap modeling, Elf will still ignore the invoke() call in line 15 as v points to objects of unknown types as discussed above. L3. Design-Time Soundness, Precision and Scalability When analysing a program heuristically, a best-effort approach does not know which reflective calls may potentially affect its soundness, precision and scalability. As a result, a developer is out of luck with a program if such best-effort analysis is either unscalable or scalable but with undesired soundness or precision or both. 2.3 Solar: Soundness-Guided Reflection Resolution Fig. 2 illustrates the Solar design, with its three novel aspects marked by N1 – N3, where Ni is introduced to overcome the afore-mentioned limitation Li. Scalable Unscalable Satisfied Soundness Proven Java Programs Violated Impreicse Unsound N1 Lazy Heap Modelling Soundness Criteria Imprecision Criteria ( by Customized Thresholds ) PROBE Reflective Calls Lightweight Annotations Automatic Identification of Problematic Reflective Calls N2 Collective Inference N3 Fig. 2. Solar: a soundness-guided analysis with three novel aspects, N1 – N3. N1. Lazy Heap Modeling (LHM) Solar handles reflective object creation lazily by delaying the creation of objects at their usage points where their types may be inferred, achieving significantly improved soundness and precision. Let us describe the basic idea behind using the example in Fig. 1. As cName at c1 = Class.forName(cName) in line 2 is unknown, Solar will create a Class metaobject c1u that represents this unknown class and assign it to c1. As c1 points to c1u at the allocation site v = c1.newInstance() in line 3, Solar will create an abstract object o u 3 of an unknown type for the site to mark it as being unresolved yet. Subsequently, o u 3 will flow into two usage points: Case (I) a type cast operation in line 12 and Case (II) a reflective method call site in line 15. In Case (I), where o u 3 is downcast to A, its type u is inferred to be A or any of its subtypes. Let t1, . . . , tn be all the inferred types. Then o u 3 is split into n