Naming Java Entities

In bytecode, there can be more than one name for a single given entity that arises at runtime.

For example, suppose you have classes A and B in package foo, where A extends B. Further, neither A nor B overrides java.lang.Object.toString().

The following are all legal names for a method that might arise in the bytecode:

• < Application, Lfoo/A, toString() >
• < Application, Lfoo/B, toString() >
• < Application, Ljava/lang/Object, toString() >
• < Primordial, Ljava/lang/Object, toString() >

However at run-time, these will all be resolved to a single entity: < Primordial, Ljava/lang/Object, toString()>.

In WALA, an IMethod represents the unique entity that will arise at run-time, while a MethodReference can represent any of the possible names that arise in the bytecode.

Similarly, an IClass represents the unique entity that will arise at run-time, while a TypeReference can represent any of the possible names for a type that arise at runtime. Note that in Java the unique name of a class is actually a pair of a classloader x packagename.typename. So a TypeReference actually consists of a ClassLoaderReference x TypeName.

There's similar logic between FieldReference and IField, and ClassLoaderReference and IClassLoader.

A ClassHierarchy object allows for resolving references to run-time entities (e.g., getting an IMethod object from a MethodReference): see ClassHierarchy.resolveMethod(), ClassHierarchy.resolveField(), etc. (see UserGuide:ClassHierarchy for more details on class hierarchies).

Note that most names of entities (e.g. TypeReference, TypeName, MethodReference) are canonicalized via hash-consing, to save space.