§B.1 Paragraphs changed between versions

(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.

  • §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.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.