text: Lifting in call hierarchy
  since 2.1M6
  301314
  Previously, the call hierarchy for a role constructor was incomplete because
  roles can be constructed on-demand by lifting.
  To visualize this implicit behavior the call hierarchy has been extended to
  consider occurrences of lifting as invocations of the role's lifting constructor.
  Here the call hierarchy was opened for the role type Item to find all paths towards instantiation.
  The call hierarchy shows the callin binding earchCredit <- after book because it may
  trigger lifting a Segment to its Item role.
  Item
  earchCredit <- after book
  Segment
  Add signatures to method binding
  since 2.1M2
  355274
  The existing quick assist "Add signatures to method binding" has been improved
  so that it can be used on a a signature-less method binding even if it fails to resolve its base method(s).
  In case the base class has more than one method of the name mentioned in the method binding,
  all matching base methods are collected, the best match is inserted into the editor
  and other matches are offered as alternatives in linked mode.
  So, if before invoking the assist you have:
  you may invoke the assist as a quickfix (e.g., from the error hover), producing this change:
  where you may select the suitable base method from a list.
  Hint: If a method binding has an incorrect signature you may first remove signatures (using a quick assist)
  and then let this new assist insert correct signatures.
  Implement abstract methods from implicit super role
  since 2.1M3
  348574
  The existing quick assist "Add unimplemented methods" has been extended to apply also to those abstract methods
  that are implicitly inherited from the corresponding role in the super team.
  The error against the role class now provides the quick fix:
  Invoking the quick fix (e.g., from the error hover) produces this change:
  Improved handling of base imports
  since 2.1M5
  356003
  So-called "base imports" are used in OT/J to distinguish those classes that are imported only as a base class of
  a role in the current team, disallowing direct use within the implementation of the team and its roles (see OTJLD §2.1.2(d)).
  The umbrella bug 356003 lists several individual improvements to make content assist, wizards, and refactoring
  better aware of the semantic rules of base imports.
  In all these situations the correct base import or regular imported is now created,
  and base imports are correctly updated if mandated by a refactoring.
  Basic code formatting for OT/J
  since 2.1M5
  331731
  In previous versions support for code formatting for OT/J was incomplete, and the occurrence of some
  constructs like precedence made the formatter silently fail.
  As of 2.1 M5 code formatting for OT/J now generally works for all language constructs.
  Results may not be optimal for all syntax elements because no special preference options have been introduced
  for elements like callin / callout. However, users who don't object to the default formatting style
  can now rely on automatic formatting of roles and teams.
  precedence
  Java 7 support
  since 2.1M1
  353894
  Starting with 2.1 M1, OT/J has been integrated with Java 7, i.e., the OT/J compiler also supports all
  new features introduced in Java 7.
  @Override for static role methods
  since 2.1M3
  359894
  Along implicit inheritence a role can override even a static method from its implicit super role.
  This overriding can now be documented using an @Override annotation,
  which will cause the compiler to check if the claimed overriding actually happens:
  @Override
  public team class T0 {
  protected class R {
  static int zork() { return 0;}
  }
  }
  public team class T1 extends T0 {
  @Override
  protected class R {
  @Override // OK
  static int zork() { return 1;}
  @Override // ERROR
  static void bar() { }
  }
  }
  public team class
  protected class
  static int
  extends
  // OK
  // ERROR
  static void
  Base class as method return
  since 2.1M6
  370273
  Mentioning a base imported class in the body of a team or role is not allowed.
  However, a team method may want to return a role which then should be lowered on the way.
  Previously, this lowering was not possible, because the base type could not be mentioned (by its simple name).
  For the specific situation of team method return types this restriction has been removed.
  import base some.pack.Base; // base import restricts usage of "Base"
  public team class T {
  protected class R playedBy Base { }
  private R r;
  public Base getObject() {
  return this.r; // applies lowering
  }
  }
  import base
  playedBy
  private
  public
  return this
  Simplified launching with OT/Equinox
  since 2.1M4
  366315
  OT/Equinox is implemented using a fragment that acts as a framework extension for Equinox.
  So far this required that the OT/Equinox bundles be located in the same place were also the org.eclipse.osgi
  is located.
  This could make it difficult to debug OT/Equinox itself, because then all mentioned bundles would have to be setup
  as projects physically stored in the workspace.
  org.eclipse.osgi
  This restriction has been removed, i.e., the OT/Equinox bundles may be resolved from the workspace while
  org.eclipse.osgi is resolved from the base platform.
  Hot code replacement
  since 2.1M7
  378176
  378195
  Previously, when debugging an OT/J or OT/Equinox application,
  changes made to the source code of the running application could not be applied on the fly,
  because the JVM would detect signature mismatches.
  This was caused by the fact that during hot code replacement the Object Teams bytecode transformer was not used.
  This has been fixed by enabling the Object Teams transformer to re-weave already loaded classes.
  Additionally, for OT/Equinox debug launches a new Java agent has been developed
  to trigger weaving also for hot code replacement (which is not supported by the underlying adaptor hooks in Equinox).
  This agent is automatically added to the Java command line for all OT/Equinox debug launches.
  As the result it is now possible to directly see the effect of source code changes even in woven
  classes without restarting the application. Note, that hot code replacement is limited by the JVM
  to changes that do not affect any signatures.
  Report multiple callins
  since 2.1M2
  314610
  When two independent callin bindings affect the same base method this might give rise to unanticipated behavior.
  Therefor a new warning is reported to alert the user of this situation:
  As mentioned in the warning message, this diagnostic is recomputed only during full builds,
  because this computation requires a whole system analysis.
  Use the callin marker in the left ruler to navigate to the potentially conflicting callin bindings for inspection
  (sorry for the clutter between the callin marker and the warning marker):
  Memory optimization
  since 2.1M2
  355328
  Memory consumption of the OTRE could be reduced significantly.
  A given class from BCEL was retaining the full structure for loaded classes, which could be reduced to a much more compact format.
  Measurements showed a reduction of this data structure to approx. 1% of the original size.
  Performance optimization
  since 2.1M2
  355263
  An internal data structure woven into each base class was initialized eagerly causing a performance penalty.
  This eager initialization could be removed completely, lazy initialization was already implemented.
  For situations where lots of base objects were created for which no role was ever created
  this results in a speedup of up-to 3.5 (from a micro benchmark).
  Source bundles
  since 2.1M6
  370650
  We now ship an additional (optional) feature, org.eclipse.objectteams.otdt.source.feature
  that includes the source code of all Object Teams plug-ins to support browsing into binary plug-ins
  on which plug-in projects in the workspace depend.
  org.eclipse.objectteams.otdt.source.feature