OTDT 1.3 - New and Noteworthy

Views

Colored labels since 1.2.1
#118

Colored labels are now supported for method mappings, too:

• Search view and Call hierarchy can now display method mappings (callin/callout) with colored labels. By default this capability is used for displaying the declaring class in a shaded font color.

  
  

  Previously, earnCredit <- book would be displayed without the grey suffix.

Content Assist

Improved completion
since 1.2.1, since 1.2.2
several

Improvements regarding code completion:

• Base-call completion is more robust now, see#134
• Method bindings to invisible base features (private features of super-classes) are no longer proposed, see#138.
• Internal variables (starting with _OT$) are no longer proposed as arguments to a method call, see#126.
• since 1.2.2 Completion after tsuper. now only proposes the correct overridden method from the implicit super role, see#45.

Improved and new quickfixes
since 1.2.1
several

The following quickfixes have been added or improved:

• Cross-file corrections since 1.2.1
  Previously, in OT/J code some quickfixes worked only within the current source file. This limitation has been removed in #12, #120
• Role constructor visibility: since 1.2.1
  Previously, the visibility of a role constructor could not be changed using a quickfix (this happened, because role constructors are internally translated to team-level methods). This limitation has been removed in #120
• Add unimplemented methods: since 1.2.1
  Implicitly inherited abstract methods can now be added using a quickfix just like explicitly inherited ones. #143
  

Launching

Unified Launch Configuration Types
since 1.2.1,since 1.2.2
#137

Standard launches now support OT/J — (for migrating old launches see below)

The OT/J specific launch types ( Object Teams Application, Object Teams Eclipse Application OT/Equinox Framework) are no longer needed and are gradually being faded out. Instead simply select one of these standard launch types

• Java Application
• JUnit
• JUnit Plug-in Test
• Eclipse Application
• OSGi Framework

Language

Baseclass generalization
since 1.2.1

Base bounded type parameters
A new kind of bound for type parameters has been introduced in order to express that a team method expects as an argument any value that can be lifted to a given role type. This allows to generalize over otherwise unrelated base classes.
The new syntax is:

This method can be invoked with an argument of any type that can be lifted to Role0 which means the provided value must be conform to a base class Base1 that is bound to a given role Role1 (Role1 playedBy Base1) where Role1 is a subtype or equal Role0.

Incompatible covariance
since 1.2.1

The compiler now detects and correctly reports a situation where different incompatible versions of the same method are inherited along different paths. This can happen by an unfortunate combination of implicit inheritance and a covariantly redefined return type.
See this example (visibility modifiers omitted):

team class T1 {
  class R1 {
    A m() { return new A(); }
  }
  class R2 extends R1 {
    A m() { return new A(); }
  }
}
team class T2 extends T1 {
  class R1 { // overrides T1.R1
    B m() { return new B(); } // given B subtype of A, thus: covariant return type
  }
  // implicit role R2 inherits conflicting methods m() from T1.R2 and T2.R1.
}

In this example, role T2.R2 implicitly inherits m() from T1.R2 (returning A), which, however, is not compatible to the super version from T2.R1 (returning B). This is thus a violation against the new 1.3.1(k).

Import in role files
since 1.2.2
#60

A small new paragraph in the OTJLD, 1.2.5(f) defines how imports for role files are evaluated.

Role inheriting from regular class
since 1.2.3
#121

A small new paragraph in the OTJLD, 1.3.2(e) clarifies the visibility of non-public methods which a role inherits from a non-role superclass. The essence of this rule is that such methods are accessible within the role but not exposed to clients of the role.

Base super call
since 1.2.4
#158

This new feature has been introduced as 4.3(f). It solves a problem which typically arises, if a callin method replaces a base method containing a super-call, where this super-call should then be issued from the callin method instead. To support this situation the following syntax is introduced:

Runtime

Weaving into system classes
since 1.2.3
#149

It is now possible to bind a role to a system class as its base class. Here "system class" means any class that is loaded via the bootstrap classpath, i.e., normally all classes from rt.jar. To leverage this feature, applications must be launched using the JPLIS mode, which otherwise has graduated from experimental status to being fully equivalent to the old JMangler based mode.

Still not all classes can be bound, simply because the runtime environment cannot intercept classes that were loaded before it could start its work. For that sake the compiler issues a warning when binding into classes from any java... or javax... packages (see #64)

OT/Equinox

OT/Equinox dependencies
since 1.2.1
#128

OT/Equinox has now even fewer dependencies.
Previously, OT/Equinox had a dependency on org.eclipse.core.runtime thus constraining the use of OT/Equinox in "pure" OSGi applications. As of 1.2.1 these dependencies have been reduced to:

• org.eclipse.equinox.common
• org.eclipse.equinox.registry
• org.eclipse.osgi