ProjectLike
Related Doc:
package analyses
The class file of java.lang.invoke.MethodHandle, if available.
The set of all subtypes of java.lang.invoke.MethodHandle; in particular required to
resolve signature polymorphic method calls.
The class file of java.lang.Object, if available.
Returns the set of all non-private, non-abstract, non-static methods that are not initializers and which are potentially callable by clients when we have an object that has the specified type and a method is called using org.opalj.br.instructions.INVOKEINTERFACE, org.opalj.br.instructions.INVOKEVIRTUAL or org.opalj.br.instructions.INVOKEDYNAMIC.
Returns the set of all non-private, non-abstract, non-static methods that are not initializers and which are potentially callable by clients when we have an object that has the specified type and a method is called using org.opalj.br.instructions.INVOKEINTERFACE, org.opalj.br.instructions.INVOKEVIRTUAL or org.opalj.br.instructions.INVOKEDYNAMIC.
The array of methods is sorted using MethodDeclarationContextOrdering to
enable fast look-up of the target method. (See MethodDeclarationContext's
compareAccessibilityAware method for further details.)
Stores for each non-private, non-initializer method the set of methods which override a specific method.
Stores for each non-private, non-initializer method the set of methods which override
a specific method. If the given method is a concrete method, this method is also
included in the set of overridingMethods.
Computes the maximally specific superinterface method with the given name and descriptor
Computes the maximally specific superinterface method with the given name and descriptor
A set of interfaces which potentially declare a method with the given name and descriptor.
Computes the set of maximally specific superinterface methods with the given name and descriptor.
Computes the set of maximally specific superinterface methods with the given name and descriptor.
This method does not consider methods defined by java.lang.Object!
Those methods have precedence over respective methods defined by
superinterfaces! A corresponding check needs to be done before calling
this method.
Tests if the given method belongs to the interface of an object identified by the given
objectType.
Tests if the given method belongs to the interface of an object identified by the given
objectType.
I.e., returns true if a virtual method call, where the receiver type is known
to have the given objectType, would lead to the invokation of the given method.
The given method can be an inherited method, but it will never return Yes if
the given method is overridden by objectType or a supertype of it which is a
sub type of the declaring type of method.
The computation is based on the computed set of instanceMethods and generally requires at most O(n log n) steps where n is the number of callable instance methods of the given object type; the class hierarchy is not traversed.
Returns the (instance) method that would be called when we have an instance of the given receiver type.
Returns the (instance) method that would be called when we have an instance of the given receiver type. I.e., using this method is suitable when the runtime type, which is the receiver of the method call, is precisely known!
This method supports default methods and signature polymorphic calls.
The object type which defines the method which performs the call. This information is required if the call target has (potentially) default visibility. (Note that this - in general - does not replace the need to perform an accessibility check.)
A class type or an array type; never an interface type.
Returns the methods that may be called by org.opalj.br.instructions.INVOKEINTERFACE if the precise runtime type is not known.
Returns the methods that may be called by org.opalj.br.instructions.INVOKEINTERFACE
if the precise runtime type is not known. (If the precise runtime type is known use
instanceCall to get the target method.)
Keep in mind that the following is legal (byte)code:
class X { void m(){ System.out.println("X.m"); } } interface I { void m(); } class Z extends X implements I {}
Hence, we also have to consider inherited methods and just considering the
methods defined by subclasses is not sufficient! In other words, the result
can contain methods (here, X.m) defined by classes which are not subtypes
of the given interface type!
Caching the result (in particular when the call graph is computed) is recommended as the computation is expensive.
Returns true if the method defined by the given class type is a signature polymorphic method.
Returns true if the method defined by the given class type is a signature polymorphic method. (See JVM 8 Spec. for details.)
Returns all classes that implement the given method by searching all subclasses
of receiverType for implementations of the given method and also considering
the superclasses of the receiverType up until the class (not interface) that
defines the respective method.
Returns all classes that implement the given method by searching all subclasses
of receiverType for implementations of the given method and also considering
the superclasses of the receiverType up until the class (not interface) that
defines the respective method.
An upper bound of the runtime type of some value. If the type
is known to be precise (i.e., it is no approximation of the runtime type)
then it is far more meaningful to directly call lookupMethodDefinition.
The name of the method.
The method's descriptor.
A function that returns true, if the runtime type of
the receiverType may be of the type defined by the given object type. For
example, if you analyze a project and perform a lookup of all methods that
implement the method toString, then this set would probably be very large.
But, if you know that only instances of the class (e.g.) ArrayList have
been created so far
(up to the point in your analysis where you call this method), it is
meaningful to sort out all other classes (such as Vector).
Looks up the class file and method which actually defines the method that is referred to by the given receiver type, method name and method descriptor.
Looks up the class file and method which actually defines the method that is referred to by the given receiver type, method name and method descriptor. Given that we are searching for method definitions the search is limited to the superclasses of the class of the given receiver type.
This method does not take visibility modifiers or the static modifier into account. If necessary, such checks need to be done by the caller.
This method supports resolution of signature polymorphic methods
(in this case however, it needs to be checked that the respective invoke
instruction is an invokevirtual instruction.)
Some(Method) if the method is found. None if the method
is not found. This can basically happen under two circumstances:
First, not all class files referred to/used by the project are (yet) analyzed;
i.e., we do not have all class files belonging to this project.
Second, the analyzed class files do not belong together (they either belong to
different projects or to incompatible versions of the same project.)
To get the method's defining class file use the project's respective method.
In case that you analyze static source code dependencies and if an invoke instruction refers to a method that is not defined by the receiver's class, then it might be more meaningful to still create a dependency to the receiver's class than to look up the actual definition in one of the receiver's super classes.
lookupMethodDefinition(ObjectType,String,MethodDescriptor,ClassFileRepository)
Looks up the method (declaration context) which is accessible/callable by an
org.opalj.br.instructions.INVOKEVIRTUAL or org.opalj.br.instructions.INVOKEINTERFACE
call which was done by a method belonging to callingContextType.
Looks up the method (declaration context) which is accessible/callable by an
org.opalj.br.instructions.INVOKEVIRTUAL or org.opalj.br.instructions.INVOKEINTERFACE
call which was done by a method belonging to callingContextType.
The callingContextType is only relevant in case the target method has default visibility;
in this case it is checked whether the caller belongs to the same context.
Success if the method is found; Empty$ if the method cannot be found and Failure$ if the method cannot be found because the project is not complete. Hence, Empty$ may be indicative of an inconsistent project, if this lookup is expected to succeed.
It supports the lookup of polymorphic methods.
,This method uses the pre-computed information about instance methods and, therefore, does not require a type hierarchy based lookup.
Returns the set of methods which directly override the given method.
Returns the set of methods which directly override the given method. Note that
overriddenBy is not context aware. I.e., if a given method m is an interface
method, then it may happen that we have an implementation of that method
in a class which is inherited from a superclass which is not a subtype of the
interface. That method - since it is not defined by a subtype of the interface -
would not be included in the returned set. An example is shown next:
class X { void m(){ System.out.println("X.m"); } interface Y { default void m(){ System.out.println("Y.m"); } class Z extends X implements Y { // Z inherits m() from X; hence, X.m() (in this context) "overrides" Y.m(), but is not // returned by this function. To also identify X.m() you have to combine the results // of overridenBy and instanceMethods(!). }
org.opalj.Success(method) if the method was found;
Failure if the project is incomplete and the method could not be found;
Empty if the method could not be found though the project is seemingly complete.
I.e., if Empty is returned the analyzed code basis is most likely
inconsistent.
resolveFieldReference(ObjectTypeString,FieldType):Option[Field]
Resolves a symbolic reference to a field.
Resolves a symbolic reference to a field. Basically, the search starts with
the given class c and then continues with c's superinterfaces before the
search is continued with c's superclass (as prescribed by the JVM specification
for the resolution of unresolved symbolic references.)
Resolving a symbolic reference is particularly required to, e.g., get a field's
annotations or to get a field's value (if it is static, final and has a
constant value).
The class (or a superclass thereof) that is expected to define the reference field.
The name of the accessed field.
The type of the accessed field (the field descriptor).
The field that is referred to; if any. To get the defining ClassFile
you can use the project.
Resolution is final. I.e., either this algorithm has found the defining field or the field is not defined by one of the loaded classes. Searching for the field in subclasses is not meaningful as it is not possible to override fields.
,This implementation does not check for IllegalAccessError. This check
needs to be done by the caller. The same applies for the check that the
field is non-static if get-/putfield is used and static if a get-/putstatic is
used to access the field. In the latter case the JVM would throw a
LinkingException.
Furthermore, if the field cannot be found, it is the responsibility of the
caller to handle that situation.
Tries to resolve a method reference as specified by the JVM specification.
Tries to resolve a method reference as specified by the JVM specification. I.e., the algorithm tries to find the class that actually declares the referenced method. Resolution of signature polymorphic method calls is also supported.
This method can be used as the basis for the implementation of the semantics
of the invokeXXX instructions. However, it does not check whether the resolved
method can be accessed by the caller or if it is abstract. Additionally, it is still
necessary that the caller makes a distinction between the statically
(at compile time) identified declaring class and the dynamic type of the receiver
in case of invokevirtual and invokeinterface instructions. I.e.,
additional processing is necessary on the client side.
If true (default: false) the method tries to look up the method in a super interface if it can't find it in the available super classes. (This setting is only relevant if the class hierarchy is not complete.)
The resolved method Some(METHOD) or None.
(To get the defining class file use the project's respective method.)
This method just resolves a method reference. Additional checks, such as whether the resolved method is accessible, may be necessary.
Returns the instance method/initializer which is called by an invokespecial instruction.
Returns the instance method/initializer which is called by an invokespecial instruction.
One of the following three values:
(method) if the method was found;Failure if the project is definitively incomplete and the method could not
be found;Empty if the method could not be found though the project is seemingly complete.
I.e., if Empty is returned the analyzed code basis is most likely
inconsistent.Virtual method call resolution is not necessary; the call target is either a constructor, a private method or a super method/constructor. However, in the last case it may be possible that we can't find the method because of an incomplete project. In that case the result will be Empty$. If the project is complete, but we can't find the class the result is Failure$; this is indicative of an inconsistent project.
Returns the method that will be called by the respective invokestatic call.
Returns the method that will be called by the respective invokestatic call. (The client may require to perform additional checks such as validating the visibility!)
org.opalj.Success (method) if the method was found;
Failure if the project is incomplete and the method could not be found;
Empty if the method could not be found though the project is seemingly complete.
I.e., if Empty is returned the analyzed code basis is most likely
inconsistent.
Returns the method which will be called by the respective org.opalj.br.instructions.INVOKESTATIC instruction.
Returns the set of methods that may be called by an invokevirtual call, if the return type is unknown.
Enables project wide lookups of methods and fields as required to determine the target(s) of an invoke or field access instruction.
The current implementation is based on the correct project assumption; i.e., if the bytecode as a whole is not valid, the result is generally undefined. One example would be, if we have two interfaces which define a non-abstract method with the same signature and both interfaces are implemented by a third interface which does not override these methods. In this case the result of a
resolveMethodReferenceis not defined, because the code base as a whole is not valid.