distinct objects o3,...,o"to be assigned to a in line 12.In Case (II),SOLAR will infer u by performing a collective inference as described below,based on the information available in line 15.Let t,...,tm be all the inferred types.Then og is split into m distinct objectsoto be assigned to v in line 15. According to Assumption 4 that states a key observation validated later,a reflectively created object like o is typically used in either Case(I)or Case(II) along every program path.The only but rare exception is that o is created but never used later.Then the corresponding constructor must be annotated to be analyzed statically unless ignoring it will not affect the points-to information. N2.Collective Inference SoLAR builds on the prior work [5,17,18,20,22,21] by relying on collective inference emphasized for the first time in reflection anal- ysis.Let us return to the invoke()call,which cannot be analyzed previously. As v points to o,SoLAR can infer u based on the information available at the call site.This happens when Case (1)cName2 is known or Case(2)cName2 is unknown but mName2 is known.In SOLAR,inference is performed "collectively" whereby inferences on related reflective calls(lines 3,6 and 15 for Case(1)and lines 3.7 and 15 for Case(2))can mutually reinforce each other.We will examine the second case,i.e.,the more complex of the two,in Section 3.4.3.This paper is the first to do so by exploiting the connection between newInstance()(via LHM)and reflective calls for manipulating methods and fields. N3.Automatic Identification of "Problematic"Reflective Calls Due to this capability,SoLAR is the first that can reason about its soundness.When such reasoning is not possible due to,e.g.,native code,SoLAR reduces to an effective under-approximate analysis due to its soundness-guided design,allowing a disciplined tradeoff to be made among soundness,precision and scalability. If SOLAR is scalable for a program,SoLAR can automatically identify "prob- lematic"reflective calls (as opposed to reporting input strings as in [20])that may threaten its soundness and precision to enable both to be improved with lightweight annotations.If SoLAR is unscalable for a program,a simplified ver- sion of SOLAR,denoted PROBE in Fig.2,is called for next.With some "prob- lematic"reflective calls to be annotated,SoLAR will re-analyze the program, scalably after one or more iterations of this "probing"process.We envisage providing a range of PROBE variants with different tradeoffs among soundness, precision and scalability,so that the scalability of PROBE is always guaranteed. Consider Fig.1 again.If both cName2 and mName2 are unknown (given that the type of o is unknown),then SoLAR will flag the invoke()call in line 15 as being potentially unsoundly resolved,detected automatically by verifying Condition(3)in Section 3.5.In addition,SoLAR will also automatically highlight reflective calls that may be potentially imprecisely resolved.Their lightweight annotations will allow SoLAR to yield improved soundness and precision. Discussion Under Assumptions 1-4,we can establish the soundness of So- LAR by verifying a soundness criterion (given in Section 3.5).Otherwise,our soundness-guided approach has made SoLAR demonstrably more effective than existing under-approximate reflection analyses [5,17,20,21]as validated later.distinct objects o t1 3 ,. . . , o tn 3 to be assigned to a in line 12. In Case (II), Solar will infer u by performing a collective inference as described below, based on the information available in line 15. Let t 1 1 , . . . , t1 m be all the inferred types. Then o u 3 is split into m distinct objects o t 1 1 3 ,. . . , o t 1 m 3 to be assigned to v in line 15. According to Assumption 4 that states a key observation validated later, a reflectively created object like o u 3 is typically used in either Case (I) or Case (II) along every program path. The only but rare exception is that o u 3 is created but never used later. Then the corresponding constructor must be annotated to be analyzed statically unless ignoring it will not affect the points-to information. N2. Collective Inference Solar builds on the prior work [5, 17, 18, 20, 22, 21] by relying on collective inference emphasized for the first time in reflection anal￾ysis. Let us return to the invoke() call, which cannot be analyzed previously. As v points to o u 3 , Solar can infer u based on the information available at the call site. This happens when Case (1) cName2 is known or Case (2) cName2 is unknown but mName2 is known. In Solar, inference is performed “collectively”, whereby inferences on related reflective calls (lines 3, 6 and 15 for Case (1) and lines 3, 7 and 15 for Case (2)) can mutually reinforce each other. We will examine the second case, i.e., the more complex of the two, in Section 3.4.3. This paper is the first to do so by exploiting the connection between newInstance() (via LHM) and reflective calls for manipulating methods and fields. N3. Automatic Identification of “Problematic” Reflective Calls Due to this capability, Solar is the first that can reason about its soundness. When such reasoning is not possible due to, e.g., native code, Solar reduces to an effective under-approximate analysis due to its soundness-guided design, allowing a disciplined tradeoff to be made among soundness, precision and scalability. If Solar is scalable for a program, Solar can automatically identify “prob￾lematic” reflective calls (as opposed to reporting input strings as in [20]) that may threaten its soundness and precision to enable both to be improved with lightweight annotations. If Solar is unscalable for a program, a simplified ver￾sion of Solar, denoted Probe in Fig. 2, is called for next. With some “prob￾lematic” reflective calls to be annotated, Solar will re-analyze the program, scalably after one or more iterations of this “probing” process. We envisage providing a range of Probe variants with different tradeoffs among soundness, precision and scalability, so that the scalability of Probe is always guaranteed. Consider Fig. 1 again. If both cName2 and mName2 are unknown (given that the type of o u 3 is unknown), then Solar will flag the invoke() call in line 15 as being potentially unsoundly resolved, detected automatically by verifying Condition (3) in Section 3.5. In addition, Solar will also automatically highlight reflective calls that may be potentially imprecisely resolved. Their lightweight annotations will allow Solar to yield improved soundness and precision. Discussion Under Assumptions 1 – 4, we can establish the soundness of So￾lar by verifying a soundness criterion (given in Section 3.5). Otherwise, our soundness-guided approach has made Solar demonstrably more effective than existing under-approximate reflection analyses [5, 17, 20, 21] as validated later