Looks for possible 'this' escapes and generates corresponding warnings.

A 'this' escape occurs in the following scenario:

• There is some class A and some subclass B that extends it
• A defines an instance method m() which is overridden in B
• Some constructor B() invokes some superclass constructor A()
• At some point during the execution of A(), method m() is invoked and the reciever for the instance method is the new instance being constructed by B()

This represents a problem because the method B.m() will execute before the constructor B() has performed any of its own initialization.

This class attempts to identify possible 'this' escapes while also striking a balance between false positives, false negatives, and code complexity. We do this by "executing" the code in candidate constructors and tracking where the original 'this' reference goes. If it passes to code outside of the current module, we declare a possible leak.

As we analyze constructors and the methods they invoke, we track the various object references that might reference the 'this' instance we are watching (i.e., the one under construction). Such object references are represented by the Ref class hierarchy, which models the various ways in which, at any point during the execution of a constructor or some other method or constructor that it invokes, there can live references to the object under construction lying around. In a nutshell, the analyzer keeps track of these references and watches what happens to them as the code executes so it can catch them in the act of trying to "escape".

The Ref sub-types are:

• ThisRef - The current 'this' instance of the (instance) method being analyzed
• ExprRef - The current expression being evaluated, i.e., what's on top of the Java stack
• VarRef - Local variables and method parameters currently in scope
• YieldRef - The current switch expression's yield value(s)
• ReturnRef - The current method's return value(s)

Currently we don't attempt to explicitly track references stored in fields (for future study).

For each object reference represented by a Ref, we track up to three distinct ways in which it might refer to the new 'this' instance: the reference can be direct, indirect, or via an associated enclosing instance (see Indirection).

A few notes on this implementation:

• We "execute" constructors and track how the Ref's evolve as the constructor executes.
• We use a simplified "flooding" flow analysis where every possible code branch is taken and we take the union of the resulting Ref's that are generated.
• Loops are repeated until the set of Ref's stabilizes; the maximum number of iterations possible is proportional to the number of variables in scope.
• An "escape" is defined as the possible passing of a subclassed 'this' reference to code defined outside of the current module.
  • In other words, we don't try to protect the current module's code from itself.
  • For example, we ignore private constructors because they can never be directly invoked by external subclasses, etc. However, they can be indirectly invoked by other constructors.
• If a constructor invokes a method defined in the same compilation unit, and that method cannot be overridden, then our analysis can safely "recurse" into the method.
  • When this occurs the warning displays each step in the stack trace to help in comprehension.
• We assume that native methods do not leak.
• We don't try to follow super() invocations; that's for the superclass analysis to handle.

This is NOT part of any supported API. If you write code that depends on this, you do so at your own risk. This code and its internal interfaces are subject to change or deletion without notice.