of supporting dynamic adaptation of object-oriented software.As such.metaob- jects are often created reflectively as shown in Fig.1 from input strings.Thus, reflective object creation via newInstance()is hard to model statically.Finally. picking judicious approximations to balance soundness,precision and scalability is non-trivial.A simple-minded sound modeling of a reflective call (e.g.,by as- suming arbitrary behaviour)would destroy precision.Imprecision,in turn,often destroys scalability because too many spurious results would be computed. SOLAR automates reflection analysis for Java by working with a pointer anal- ysis.We first define some assumptions (Section 2.1).We then look at the three limitations of the prior work (Section 2.2).Finally,we introduce SOLAR to ad- dress these limitations by adopting three novel aspects in its design(Section 2.3). 2.1 Assumptions The first three are made previously on reflection analysis for Java [20,21].The last one is introduced to allow reflective allocation sites to be modeled lazily. Assumption 1 (Closed-World).Only the classes reachable from the class path at analysis time can be used during program erecution. This assumption is reasonable since we cannot expect static analysis to han- dle all classes that a program may conceivably download from the net and load at runtime.In addition,Java native methods are excluded as well. Assumption 2 (Well-Behaved Class Loaders).The name of the class returned by a call to Class.forName(cName)equals cName. Assumption 3(Correct Casts).Type cast operations applied to the results of reflective calls are correct,without throwing a ClassCastException. Assumption 4 (Object Reachability).Every object o created reflectively in a call to newInstance()fows into (i.e.,is used in)either (1)a type cast operation ...(T)v or (2)a call to invoke(v,...),get(v)or set(v,...),where v points to o,along every execution path in the program. As discussed in Section 4.2,Assumption 4 is found to hold for most reflective allocation sites in real code(as illustrated in Fig.1).Here,(1)and(2)represent two kinds of usage points at which the class types of object o will be inferred lazily.This makes it possible to handle reflective allocation sites more accurately than before and to reason about the soundness of SoLAR for the first time. 2.2 Past Work:Best-Effort Reflection Resolution All the existing solutions [5,17,18,20-22]adopt a best-effort approach to reflec- tion analysis,and consequently,suffer from the following three limitations: L1.Eager Heap Modeling An abstract object o created at a call to,e.g., c.newInstance()is modeled eagerly if its type c can be inferred from a string constant or intraprocedural post-dominant cast,and ignored otherwise.Specifi- cally,.if c represents a known class name,e.g,“A”,then o's type is“A”.Other- wise,an intraprocedurally post-dominating cast operation (T)operating on the result of the newInstance()call will allow c to be over-approximated as T or any of its subtypes.This eager approach often fails in real code shown in Fig.1, where cNamel is an input string and the cast is not post-dominating.Thus,itsof supporting dynamic adaptation of object-oriented software. As such, metaob￾jects are often created reflectively as shown in Fig. 1 from input strings. Thus, reflective object creation via newInstance() is hard to model statically. Finally, picking judicious approximations to balance soundness, precision and scalability is non-trivial. A simple-minded sound modeling of a reflective call (e.g., by as￾suming arbitrary behaviour) would destroy precision. Imprecision, in turn, often destroys scalability because too many spurious results would be computed. Solar automates reflection analysis for Java by working with a pointer anal￾ysis. We first define some assumptions (Section 2.1). We then look at the three limitations of the prior work (Section 2.2). Finally, we introduce Solar to ad￾dress these limitations by adopting three novel aspects in its design (Section 2.3). 2.1 Assumptions The first three are made previously on reflection analysis for Java [20, 21]. The last one is introduced to allow reflective allocation sites to be modeled lazily. Assumption 1 (Closed-World). Only the classes reachable from the class path at analysis time can be used during program execution. This assumption is reasonable since we cannot expect static analysis to han￾dle all classes that a program may conceivably download from the net and load at runtime. In addition, Java native methods are excluded as well. Assumption 2 (Well-Behaved Class Loaders). The name of the class returned by a call to Class.forName(cName) equals cName. Assumption 3 (Correct Casts). Type cast operations applied to the results of reflective calls are correct, without throwing a ClassCastException. Assumption 4 (Object Reachability). Every object o created reflectively in a call to newInstance() flows into (i.e., is used in) either (1) a type cast operation ...= (T) v or (2) a call to invoke(v,...), get(v) or set(v,...), where v points to o, along every execution path in the program. As discussed in Section 4.2, Assumption 4 is found to hold for most reflective allocation sites in real code (as illustrated in Fig. 1). Here, (1) and (2) represent two kinds of usage points at which the class types of object o will be inferred lazily. This makes it possible to handle reflective allocation sites more accurately than before and to reason about the soundness of Solar for the first time. 2.2 Past Work: Best-Effort Reflection Resolution All the existing solutions [5, 17, 18, 20–22] adopt a best-effort approach to reflec￾tion analysis, and consequently, suffer from the following three limitations: L1. Eager Heap Modeling An abstract object o created at a call to, e.g., c.newInstance() is modeled eagerly if its type c can be inferred from a string constant or intraprocedural post-dominant cast, and ignored otherwise. Specifi- cally, if c represents a known class name, e.g., “A”, then o’s type is “A”. Other￾wise, an intraprocedurally post-dominating cast operation (T) operating on the result of the newInstance() call will allow c to be over-approximated as T or any of its subtypes. This eager approach often fails in real code shown in Fig. 1, where cName1 is an input string and the cast is not post-dominating. Thus, its