Packages

  • package root
    Definition Classes
    root
  • package org
    Definition Classes
    root
  • package opalj

    OPAL is a Scala-based framework for the static analysis, manipulation and creation of Java bytecode.

    OPAL is a Scala-based framework for the static analysis, manipulation and creation of Java bytecode. OPAL is designed with performance, scalability and adaptability in mind.

    Its main components are:

    • a library (Common) which provides generally useful data-structures and algorithms for static analyses.
    • a framework for implementing lattice based static analyses (Static Analysis Infrastructure)
    • a framework for parsing Java bytecode (Bytecode Infrastructure - org.opalj.bi) that can be used to create arbitrary representations.
    • a library to create a one-to-one in-memory representation of Java bytecode (Bytecode Disassembler - org.opalj.da).
    • a library to convert this representation to Java class files (Bytecode Creator - org.opalj.bc).
    • a library to create a representation of Java bytecode that facilitates writing simple static analyses (Bytecode Representation - org.opalj.br).
    • a library to create a stackless, three-address code representation of Java bytecode that facilitates writing complex static analyses (Three Address Code - org.opalj.tac).
    • a scalable, easily customizable framework for the abstract interpretation of Java bytecode (Abstract Interpretation Framework - org.opalj.ai).
    • a library to extract dependencies between code elements (Dependencies Extraction - org.opalj.de) and to facilitate checking architecture definitions (Architecture Validation - org.opalj.av).
    • a library for the lightweight manipulation and creation of Java bytecode (Bytecode Assembler - org.opalj.ba).
    • a library for parsing Android packages (APK - org.opalj.apk).
    • libraries for writing static analyses using the interprocedural finite distributive subset (IFDS - org.opalj.ifds) and interprocedural distributive environment (IDE - org.opal.ide) algorithms.

    General Design Decisions

    Thread Safety

    Unless explicitly noted, OPAL is thread safe. I.e., the classes defined by OPAL can be considered to be thread safe unless otherwise stated. (For example, it is possible to read and process class files concurrently without explicit synchronization on the client side.)

    No null Values

    Unless explicitly noted, OPAL does not null values I.e., fields that are accessible will never contain null values and methods will never return null. If a method accepts null as a value for a parameter or returns a null value it is always explicitly documented. In general, the behavior of methods that are passed null values is undefined unless explicitly documented.

    No Typecasts for Collections

    For efficiency reasons, OPAL sometimes uses mutable data-structures internally. After construction time, these data-structures are generally represented using their generic interfaces (e.g., scala.collection.{Set,Map}). However, a downcast (e.g., to add/remove elements) is always forbidden as it would effectively prevent thread-safety.

    Assertions

    OPAL makes heavy use of Scala's Assertion Facility to facilitate writing correct code. Hence, for production builds (after thorough testing(!)) it is highly recommend to build OPAL again using -Xdisable-assertions.

    Definition Classes
    org
  • package br

    In this representation of Java bytecode references to a Java class file's constant pool and to attributes are replaced by direct references to the corresponding constant pool entries.

    In this representation of Java bytecode references to a Java class file's constant pool and to attributes are replaced by direct references to the corresponding constant pool entries. This facilitates developing analyses and fosters comprehension.

    Based on the fact that indirect references to constant pool entries are resolved and replaced by direct references this representation is called the resolved representation.

    This representation of Java bytecode is considered as OPAL's standard representation for writing simple Scala based analyses. This representation is engineered such that it facilitates writing analyses that use pattern matching.

    Definition Classes
    opalj
  • package fpcf
    Definition Classes
    br
  • package properties
    Definition Classes
    fpcf
  • package alias
    Definition Classes
    properties
  • Alias
  • AliasEntity
  • AliasField
  • AliasFormalParameter
  • AliasPropertyMetaInformation
  • AliasReturnValue
  • AliasSourceElement
  • AliasStaticField
  • AliasUVar
  • FieldReference
  • MayAlias
  • MustAlias
  • NoAlias
  • package cg
    Definition Classes
    properties
  • package fieldaccess
    Definition Classes
    properties
  • package immutability
    Definition Classes
    properties
  • package pointsto
    Definition Classes
    properties
  • package string
    Definition Classes
    properties

package alias

Ordering
  1. Alphabetic
Visibility
  1. Public
  2. Protected

Type Members

  1. sealed trait Alias extends AliasPropertyMetaInformation with OrderedProperty

    Describes the alias properties of the associated entities.

    Describes the alias properties of the associated entities.

    Alias properties can establish a binding between a pair of entities, including definition sites, formal parameters, method return values, fields, etc. For more information, see org.opalj.tac.fpcf.analyses.alias.AliasSourceElement and org.opalj.tac.fpcf.analyses.alias.AliasEntity. The pair may consist of different types of entities, such as a field and a formal parameter.

    An alias property provides information about the relationship of the memory locations of the associated entities.

    • NoAlias can be assigned to a pair of entities, iff no execution path exists where both entities refer to the same memory location. This implies that there is a definite separation of the memory locations of the two entities, and no interference can occur when one of the entities is referenced. Note that this does not imply that, for example, the fields of the entities cannot refer to the same memory location. Example:
    Object m(Object a) {
      Object b = new Object();
      return b;
    }

    In this example, the formal parameter a and the local variable b are guaranteed to never refer to the same memory location, as b is always assigned to a new object that the formal parameter can't possibly be pointing to since the object has not been created before the method call. This ensures that the method's return value and the formal parameter never point to the same memory location.

    • MustAlias can be assigned to a pair of entities, iff both entities refer to the same memory location in every execution time at all times. This implies that at every use site of one entity, it can be replaced with the other entity (if it is defined at the current location) without changing the semantics of the program. Example:
    Object m() {
      Object a = new Object();
      Object b = a;
      return b;
    }

    In this example, the local variable a and b are guaranteed to refer to the same memory location at all times, because a is only assigned once and b is only defined once with the value of a. This means that the return value of the method can be replaced with a.

    • MayAlias can always be assigned to any given pair of entities without invalidating the results. It indicates that the two entities might refer to the same memory location but are not obligated to do so. This serves as a default/fallback value when no other property can be guaranteed. Example:
    Object m(Object a) {
      Object b = a;
      System.out.println(b);
      b = new Object();
      return b;
    }

    In this example neither MustAlias nor NoAlias can be assigned to the pair of formal parameter a and local variable b, because b initially refers to the same memory location as a but is later assigned to a new object.

    Note that the examples above are usually already optimized by the compiler and are used for illustrative purposes.

    The alias properties are ordered and form a lattice with the following order: MayAlias > MustAlias > NoAlias. This means that MayAlias is the most precise property and NoAlias is the least precise property. This allows for an analysis to return NoAlias as an intermediate result when no further information is available (because there is no reason to assume it can alias) and later refine it to MustAlias or even MayAlias if more information becomes available that indicate a MayAlias or MustAlias relation. An analysis is not allowed to return a less precise property than the one that was previously assigned to the same pair of entities.

    An analysis should attempt to be as sound as possible when assigning MustAlias or NoAlias properties, but might not always be able to do so, e.g. when a field is changed via reflection or native methods. In such cases, the analysis should document the possible unsoundness.

    Alias information is only defined at a location where both entities of the associated pair are defined. If one of the entities is not defined at the current location, the given alias property holds no information.

  2. class AliasEntity extends AnyRef

    Represents a pair of AliasSourceElements and a Context for each the elements to which an alias relationship can be assigned.

    Represents a pair of AliasSourceElements and a Context for each the elements to which an alias relationship can be assigned. It is used to query and store the associated alias property in the property store. The order of the elements is irrelevant, as the alias property is symmetric. To ensure this, the given elements might be swapped internally.

  3. case class AliasField(fieldReference: FieldReference) extends AliasSourceElement with Product with Serializable

    Represents a non-static field that is part of an alias relation.

  4. case class AliasFormalParameter(fp: VirtualFormalParameter) extends AliasSourceElement with Product with Serializable

    Represents a formal parameter of a method that is part of an alias relation.

  5. sealed trait AliasPropertyMetaInformation extends PropertyMetaInformation
  6. case class AliasReturnValue(method: Method, project: SomeProject) extends AliasSourceElement with Product with Serializable

    Represents a method return value of a method that is part of an alias relation.

  7. sealed trait AliasSourceElement extends AnyRef

    Represents a source code element which can be part of an alias relation.

    Represents a source code element which can be part of an alias relation.

    Valid elements are:

    - AliasFormalParameter: A formal parameter.

    - AliasReturnValue: A method return value.

    - AliasField: A non-static field, represented by a FieldReference.

    - AliasStaticField: A static field.

    - AliasUVar: A UVar, represented by a PUVar and a Method.

  8. case class AliasStaticField(field: Field) extends AliasSourceElement with Product with Serializable

    Represents a static field that is part of an alias relation.

  9. case class AliasUVar(persistentUVar: PUVar[ValueInformation], method: Method, project: SomeProject) extends AliasSourceElement with Product with Serializable

    Represents a UVar that is part of an alias relation.

  10. case class FieldReference(field: Field, context: Context, defSites: IntTrieSet) extends Product with Serializable

    Encapsulates a reference to a specific field.

    Encapsulates a reference to a specific field. it contains the possible definition sites of the object used to access the field and the context in which the field is referenced.

    field

    The field that is referenced

    defSites

    The possible definition sites of the field

Value Members

  1. object Alias extends AliasPropertyMetaInformation
  2. object AliasEntity
  3. object AliasSourceElement
  4. case object MayAlias extends Alias with Product with Serializable

    Indicates that the two associated entities might refer to the same memory location but are not obligated to do so.

    Indicates that the two associated entities might refer to the same memory location but are not obligated to do so.

    If this property is given as an org.opalj.fpcf.InterimResult, it is guaranteed that the final result will be MayAlias. However, it is not guaranteed that the actual relation cannot be described as MustAlias or NoAlias.

    See also

    Alias for more information about alias properties.

  5. case object MustAlias extends Alias with Product with Serializable

    Indicates that the two associated entities are guaranteed to always refer to the same memory location.

    Indicates that the two associated entities are guaranteed to always refer to the same memory location.

    If this property is given as an org.opalj.fpcf.InterimResult, the final result can be refined to MayAlias if further information becomes available that indicate a MayAlias relation.

    An analysis should attempt to be as sound as possible when assigning MustAlias as a final result, but might not always be able to do so, e.g. when a field is changed via reflection or native methods. In such cases, the analysis should document the possible unsoundness.

    See also

    Alias for more information about alias properties.

  6. case object NoAlias extends Alias with Product with Serializable

    Indicates that the two associated entities are guaranteed to never refer to the same memory location.

    Indicates that the two associated entities are guaranteed to never refer to the same memory location.

    If this property is given as an org.opalj.fpcf.InterimResult, the final result can be refined to MustAlias or MayAlias if further information becomes available that indicate a MustAlias or MayAlias relation.

    An analysis should attempt to be as sound as possible when assigning NoAlias as a final result, but might not always be able to do so, e.g. when a field is changed via reflection or native methods. In such cases, the analysis should document the possible unsoundness.

    See also

    Alias for more information about alias properties.

Ungrouped