OTDT 2.1 - New and Noteworthy

Views & Dialogs

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.

Content assist

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.

Formatting

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.

Language

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:

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

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

Run / Debug

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.

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.

Compiler

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

Object Teams Runtime Environment

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

Release Engineering

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.