# §B Changes between versions

## §B.1 Paragraphs changed between versions↑ §B

#### (1) Between OTJLD 1.0 and OTJLD 1.1

- §3.2.(a) : Parameter mappings

  Disallow parameter mappings in a role interface.

- §4.5.(d) : Replace bindings

  Disallow unsafe use of polymorphism and primitive type conversions.

- §6.1.(a) : Signatures of reflective methods

  Made two methods generic so that return values can be used without the need of casting.

- §7.2 : Confined roles

  Improved explanation.

#### (2) Between OTJLD 1.1 and OTJLD 1.2

- §1.2.1.(e): Visibility of role features

  Clarification has been added that a role can always access all the features that its enclosing team has access to.

- §2.1.2.(e): Generic roles/bases

  Relaxed the rules about generic bound roles. This change also subsumes what previously was a specific restriction in §4.1.(b).

- §3.1.(i) and §3.5.(f): Visibility of shorthand callout

  A role method defined by a shorthand callout binding can now specify a visibility modifier (see also §A.3.2), otherwise it inherits the visibility modifier of it's bound base method/field.

- §3.1.(j) and §3.5.(h): Visibility of inferred callout

  Role methods inferred as a callout binding are either `public` (inferred via interface) or `private` inferred from self call / field access.

- §3.5.(h): No explicit use of inferred callout to field

  Clarification has been added that an accessor method generated for an inferred callout to field can not be explicitly invoked.

- §4.1.(b): No callin in generic role

  A restriction has been made explicit that a generic role cannot define callin bindings.

- §4.2.(d) : Callin methods

  Slightly rephrased and extended the rule to make explicit that a callin method can indeed be intercepted using a second level callin binding.

- §6.1.(a) : Reflective methods `getAllRoles`

  More precision: answer only bound roles.

#### (3) Between OTJLD 1.2 and OTJLD 1.3

- §1.2.4.(c) : Syntax for role class literals

  Previously, the syntax `R<@t>.class` was not supported. This restriction has been removed.

- §1.3 : Teams extending non-team classes

  Previously, `org.objectteams.Team` was the super class of all team classes. As a consequence a team could not extend a non-team class. This restriction has been removed by introducing a new super-type of all teams, the interface `org.objectteams.ITeam`. This change also affects some paragraphs in §6 as members have been moved to the new interface.

- §1.5.(e) : Precedence among different implicit supers

  Corrected an inconsistency in the rules for precedence among different supers: The primary rule has always been that implicit inheritance binds stronger than explicit inheritance, however, for precedence among different implicit supers a different rule was defined.
  This has been changed such that different implicit supers are prioritized by the precedence of their enclosing teams, such that a role from an implicit super team is closer related than a role from an explicit super team.

- §2.1.2.(b) : Relaxed the rule against base class circularity

  Base class circularity as defined in §2.1.2.(b) is no longer an error but as a configurable warning. However, in the presence of base class circularity, neither callouts (§3.1.(a)) nor base constructor calls (§2.4.2) are allowed.

- §2.3.4 : Changed handling of role binding ambiguities

  A definite binding ambiguity is no longer a (suppressable) compiler error, but is signaled by the need to declare `org.objectteams.LiftingFailedException`. This way diagnostics could be moved from rather unspecific locations in the team towards those applications that could suffer at runtime from a lifting failure. While it is generally not recommended to ignore any `LiftingFailedException` catching this exception may still make sense in a few corner cases mentioned in §2.3.4.(b).

- §4.4.(c) : Further restrict result mapping in after callin bindings

  Clarify that `after` callin bindings cannot use the `->` token to map a result value.

- §4.8.(a) : Precedence declarations affecting `after` callin bindings.

  While previously the effect of precedence declarations was underspecified it has been defined that the order of elements in a precedence declaration affects their priority similar to §5.1. This implies that the execution order for `after` bindings is now reversed compared to the previous implementation. In order to visualize this in the program it is now mandatory to mark precedence declarations for after bindings with the keyword `after`.

- §4.10, §4.10.(a) : Generic callin bindings

  Minor changes to give room for new paragraph §4.10.(e).

- §5.4.1.(a) : Scope of regular binding guard

  Removed an erroneous sentence about the special identifier `result` in a regular method binding guard. Since parameter mappings are applied before evaluating the guard, the result value can be accessed through a result mapping (§4.4.(c)). Furthermore, the sentence actually confused base and role sides.

- §A.3.2, §A.3.3 : Syntax: generic method bindings

  The location of possible type parameters in a method binding has been made explicit.

#### (4) Between OTJLD 1.3 and OTJLD 1.4

- §2.1.2.(d) : No on-demand base imports

  It has been clarified that base imports cannot be on-demand imports (using the wildcard `.*`).

## §B.2 Additions between versions↑ §B

#### (1) Between OTJLD 1.0 and OTJLD 1.1

- §1.2.4.(c): Role class literal

  Made existing feature explicit and introduce new qualified class literal for externalized roles.

- §3.1.(j) and §3.5.(h) : Inferred callout

  New feature.

- §4.6.(a) : Callin-binding private methods from super classes

  Added a necessary restriction.

- §4.9 : Callin inheritance

  Clarified issues that where under-specified or insufficiently explained, specifically:

  - Effect of callin bindings on inherited or overridden base methods (§4.9.1).
  - Interplay of callin bindings and base methods with covariant return types (§4.9.3)
- §4.10: Generic replace bindings

  Reconcile type safety of replace bindings as introduced in §4.5.(d) with desirable flexibility by using type parameters.

- §7.2.(b) : Arrays of Confined

  Added a necessary restriction.

#### (2) Between OTJLD 1.1 and OTJLD 1.2

- §1.2.2.(h) : Externalized creation

  Added alternative syntax using value parameter and changed title.

- §1.2.5.(f) : Imports in role files

  Added a missing rule defining the effect of imports in role files.

- §1.3.1.(c) : @Override annotation for roles

  The regular `@Override` annotation (Java ≥5) has been extended to apply to role classes, too.

- §1.3.1.(k) : Covariant return types

  Necessary constraint for covariant return types in the presence of both implicit and explicit inheritance.

- §2.1.2.(c) : Binding to final base class

  It has been added that binding to a final base class is now considered as decapsulation, too.

- §2.2.(f) : Ambiguous lowering

  A diagnostic has been added to detect situations where lowering might be intended but fails because the declared type is `java.lang.Object`, which makes a potential lowering translation unnecessary and thus ambiguous.

- §2.3.2.(e) : Generic declared lifting

  Support passing unrelated base types into the same method with declared lifting.

- §2.6.(g) : Decapsulation via base reference

  Extended applicability of decapsulation to two more positions.

- §4.3.(f) : Base super call

  Support base calls directly to the super version of the bound base method, thus bypassing both the exact bound base method and also any further callins relating to this base method or its super version.

- §5.4.(b) : Side-effects in guard predicates

  Migrate previous note about a future feature to a regular paragraph.

- §5.4.(c) : Exceptions in guard predicates

  Clarify the effect of exceptions thrown from a guard predicate.

- §6.2.(d) : LiftingVetoException

  Added documentation for the mostly internal `LiftingVetoException` and how it could actually be used in client code.

- §6.2.(e) : Role migration

  Added two interfaces to add migration capabilities to a role class.

#### (3) Between OTJLD 1.2 and OTJLD 1.3

- §2.1.1 : Binding roles to base interfaces

  The implementation limitation mentioned in §2.1.1 has been mostly removed.

- §2.3.1.(d) : Fine-tuning role instantiation

  An annotation has been defined for modifying the semantics of lifting in order to improve performance. Also a new section has been added as §6.3 to summarize the annotation types defined in this document.

- §2.3.5 : Consequences of lifting problems

  After §2.3.4 has clarified that `LiftingFailedException` (§6.2.(d)) is indeed a checked exception, a subsection has been added defining the consequences of this exception in various program situations.

- §3.1.(k) : Callout to generic method

  Added a rule on how a callout binding may refer to a generic base method.

- §4.1.(b) : Callin binding in "unliftable" role

  Callin bindings can now be defined even in "unliftable" roles.

- §4.1.(h) : Binding to team methods

  `before` and `after` callin bindings can now bind to methods of an enclosing class, too.

- §4.8.(d) : Order when merging precedence declarations

  Clarified how several precedence declarations are merged, which was underspecified, because the C3 algorithm needs ordered inputs, but this order was not specified.

- §4.10.(e) : Propagating type parameters in callin bindings

  In addition to capturing covariant return types, a callin binding may also declared type parameters in order to propagate genericity from its base method to the role method.

- §5.3.(d) : Configuring implicit activation

  Mechanisms have been added for configuring implicit team activation. The default has been changed to not apply implicit activation. A corresponding note has also been added to §5.3

- §9.2.1.(a) : Instance constrained type parameter

  Type anchors can now be applied to type parameters, too, thus expressing a new kind of constraint on the type parameter.

#### (4) After OTJLD 1.3

- §4.1.(i): Callin to constructor

  A callin after binding can now be applied to a constructor of the base class, too.