OTDT 1.4 - New and Noteworthy

Metrics Plug-in

Re-activate
since 1.3.2
#303

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.

Configuration

Adding OT support
since 1.3.2
#299

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.

Views

Role files
since 1.3.1
#268

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
#272

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.

• a base plugin as sub-element of an aspectBinding extension in the PDE's extension editor.
• a team class in the source code editor

Bound Method Compare
since 1.4.0M1
#314

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

Content Assist

Callout token
since 1.3.1
#277

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
#169

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

Formatting method bindings
since 1.3.1
#276

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.

Debugging

Remote debugging
since 1.4.0M2
#320

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:

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

Language

Annotations
since 1.3.1
#249

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

Java compatibility
since 1.3.1
#278

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
#287

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

Implicit team activation
since 1.4.0M1
#309

Implicit team activation is now configurable
After recognizing that implicit team activation ( 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.

5.3(d)

Adapting deprecated elements
since 1.4.0M1
#315

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
#144

Team classes can now extend regular classes
Previously, all team classes were direct or indirect subclasses of org.objectteams.Team. This rule in 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
#292

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) { ... }
}

protected class  R playedBy B {
    <T> callin T rm(T arg) { ... }
    <T> T rm(T arg) <- replace T bm(T arg);
}

4.10(e)

Callin to team method
since 1.4.0M3
#384

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;
    }
}

4.1(h)

Runtime

Lifting participant
since 1.3.1
#289

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.