OTDT 1.4 - New and Noteworthy

Metrics Plug-in

since 1.3.2

Early versions of the OTDT shipped with a metrics plug-in, which was discontinued in version 1.2.0. This plug-in has now been re-activated. Computing metrics for the selected Java element (project, source folder, package or type) is now invoked via the following menu action: Source > Compute OT/J Metrics. While the computation is running a progress bar is displayed, with the standard Run in Background button. When the computation finishes the Object Teams Metrics perspective is opened, where the results can be inspected.

The Object Teams Metrics perspective


Adding OT support
since 1.3.2

A menu action is now provided for adding Object Teams support to an existing Java or Plugin project. This action adds the Object Teams nature, updates the builder, and adds the OTRE to the build path.

Adding OT support


Role files
since 1.3.1

The package explorer now remembers whether role files are displayed physically (as file) or logically (as team members) (this is toggled using the button) (part 2 of #268).

Vizualize Aspect Bindings
since 1.3.2

The package explorer now displays aspect bindings of an OT/Equinox project next to the classpath containers like JRE, Plug-in Dependencies, and the OTRE. Under a single node  OT/Equinox Aspect Bindings all Base Plugins are listed that are adapted using aspect bindings. Below each base plugin the team classes are listed that implement this adaptation.

Aspect bindings in the package explorer

Double clicking a base plugin or a team shows the corresponding element in an editor:
  • a base plugin as sub-element of an aspectBinding extension in the PDE's extension editor.
  • a team class in the source code editor


Base plug-ins to which forced exports are applied are decorated with a little up-and-left arrow:

Decoration for base plug-in with forced export

Bound Method Compare
since 1.4.0M1

A new action is provided for comparing a role method with the base method to which it is bound. To invoke this action the context menu of a callin method binding (in package explorer or outline) is used: Compare With > Bound Base Method. Alternatively, the context menu can also be used on a callin method.

When invoked this action opens a compare editor, the left hand side showing the role method and the right hand side showing the bound base method. The role method is editable whereas the base method is shown read-only.

The action is most useful for callin methods that are created by copying the base method in order to apply fine grained modifications. In this situation the compare editor can be used to inspect and update the modifications as well as adopt any changes that might have occurred to the base method during evolution.

Compare menu

Compare editor for bound methods

Decorate Adapted Bundles
since 1.4.0M1

The Feature Plug-ins dialog (Help > About Eclipse SDK > FeatureX > Plug-in Details) now visualizes bundle adaption with an icon decoration in the "Signed" column. This is in addition to the textual representation in the "Version" column, which is not easily visible on platforms that do not support line breaks in table cells (the below screenshot was taken on Linux Gtk).

Feature plug-ins dialog with icon decoration

Content Assist

Callout token
since 1.3.1

A new quickfix allows to change the callout token from -> to => or back, depending on whether or not the callout actually overrides an inherited method.

Method binding completion
since 1.4.0M3

Completion within a role class can be used to create a callout or callin binding to any method of the base class. Initially this was designed for creating short-hand callout bindings, i.e., this made sense only if no method with the given name and signature already exists in the role class.
New completion proposals have now been added to create

  1. A callout binding for an abstract role method
  2. A callout override binding for a non-abstract role method
  3. A callin binding for any role method


Formatting method bindings
since 1.3.1

Formatting of method bindings has been improved such that line breaks will preferably occur before the binding token (->,=>,<-) and before the base method (if needed). This makes the binding operator stick out for better visibility.


Remote debugging
since 1.4.0M2

The OT/J extensions for the debugger can now be used for remote debugging, too. To use this feature simply check the new check box Enable OTRE in the corresponding debug launch configuration:

Remote Debugging

This will enable the "Team Monitor" view and beautify stack frames representing callin bindings etc.


since 1.3.1

Implicit inheritance now covers annotations for inherited methods and fields, too.

Java compatibility
since 1.3.1

Compatibility with a standard Java compiler has been improved, such that all Java projects that do not have the OTJavaNature project nature can use all OT/J keywords including team and within as identifiers.

Parameter mappings
since 1.3.1

Clarified rule for result mapping in callin parameter mappings
It has been clarified in OTJLD 4.4(c) that before and after callin bindings cannot define a result mapping.

Implicit team activation
since 1.4.0M1

Implicit team activation is now configurable
After recognizing that implicit team activation (OTJLD 5.3) had conceptual problems and causes a performance penalty, this feature was made configurable at two levels:

  • The system property ot.implicit.team.activation globally switches between three modes: ALWAYS, NEVER, ANNOTATED.
  • In mode ANNOTATED (default) individual methods and/or classes can be annotated with @ImplicitTeamActivation to enable implicit activation, which is otherwise disabled.
See new paragraph OTJLD 5.3(d)

Adapting deprecated elements
since 1.4.0M1

New diagnostic when adapting a deprecated class or method
A new configurable compiler diagnostic (error/warning/ignore) has been implemented, that signals all situations where a role class or one of its callin bindings adapts a deprecated class or method. Deprecation is used to mark elements that (should) become unused under evolution. Therefore, binding to deprecated elements likely signals a situation where expected trigger events will no longer occur. In that case the binding should actually be updated to another, non-deprecated element.

Teams extending regular classes
since 1.4.0M3

Team classes can now extend regular classes
Previously, all team classes were direct or indirect subclasses of org.objectteams.Team. This rule in OTJLD 1.3 has been relaxed to better support reuse of non-team classes in OT/J. If a team extends a regular class it now implicitly implements the new interface org.objectteams.ITeam, which also provides all public methods from org.objectteams.Team. It is the responsibility of the compiler to add implementations for these methods. The new interface org.objectteams.ITeam is the new common supertype of all teams since also org.objectteams.Team implements this interface.

This change maintains source-level compatibility, but unfortunately binary compatibility could not be maintained, so class files compiled by compiler versions < 1.4.0M3 can not be used together with a newer OTRE and vice verca. As a consequence a full clean build is required for all OT/J projects when upgrading to OTDT ≥ 1.4.0M3.

At source level no action is required, however, users are advised to check their code for references to org.objectteams.Team in order to migrate from using the class org.objectteams.Team to using the interface org.objectteams.ITeam instead wherever possible. Only the constant org.objectteams.Team.ALL_THREADS remains at its previous location.

Generic callin
since 1.4.0M3

Callin bindings to generic role methods
It is now possible to define a callin binding (including replace) to a generic base method, by making the callin binding generic, too. This way, genericity is propagated into the role method.
So with this base class:

public class  B {
    <T> T bm(T arg) { ... }
You can define a callin binding like this:
protected class  R playedBy B {
    <T> callin T rm(T arg) { ... }
    <T> T rm(T arg) <- replace T bm(T arg);
See new paragraph OTJLD 4.10(e)

Callin to team method
since 1.4.0M3

Callin bindings triggering team methods
If the left hand side of a callin binding does not resolve to a valid role method, also the enclosing team is searched for a compatible method. This way, a callin binding can be used as a trigger for invoking a team method, or put differently, multiple roles may share a method via their team, even when the method should be invoked by a callin binding.

public team class T {
    void teamMethod() { ... }
    protected class B playedBy B {
        teamMethod <- after baseMethod;
Note, that team methods cannot have the callin modifier. Thus, the new rule does not apply to replace callin bindings.
See new paragraph OTJLD 4.1(h)


Lifting participant
since 1.3.1

It is now possible to let client code participate in the process of creating role instances during lifting. A lifting participant must implement the interface org.objectteams.ILiftingParticipant and it is registered using the property ot.lifting.participant. An instance of that class is invoked every time lifting does not find an existing object in the team's role cache and is about to create a new instance.

This feature is used by the JPA-integration to support lazy loading of existing roles from persistent storage.