OTDT 2.0 - New and Noteworthy

Views & Dialogs

Compiler preferences page cleaned up
since 0.8.0M5
335739

The preference page for OT/J compiler options has be revamped following recent improvements in the JDT UI. The page is now structured into expandable sections per group of problems. Also incremental search within the tree of options is supported. The option to disable "scoped keywords" was apparently never used and has been removed from the preferences.

Content assist

Create role method quickfix
since 0.8.0M4
329988

If a role class has a callin binding whose left-hand side does not resolve to an existing role method a quickfix exists for creating the missing role method. Since 0.8.0M4 this quickfix respects the signature of the bound base method even if the callin binding does not declare any signatures (see the int parameter and return in the screenshot below):

Refactoring

Extract role interface
since 0.8.0M6
339264

A new option has been added to the Extract Interface refactoring: If the enclosing class is a role class a new check box appears:

If this box is checked the new interface will not be created as a top-level type (as normally done by the JDT), but as a role interface of the current enclosing team.

The refactored result looks like this

Language

Java 7 support
since 2.0.1RC1
353894

Starting with 2.0.1 RC1 OT/J has been integrated with Java 7, i.e., the OT/J compiler also supports all new features introduced in Java 7.

Precedence among tsupers
since 0.8.0M3
326969

Previously, OTJLD §1.5(e) was inconsistent between its first and second sentences. The first sentence defines the general precendence between super and tsuper, which will remain unchanged. However, the precendence among different tsupers has been adjusted as demonstrated using this example:

public team class Team0 {
   protected team class InnerTeamA {
       protected class Role {
           public void rm() { ... }
       }
       public void tm() { ... }
   }
   protected team class InnerTeamB extends InnerTeamA {
       protected class Role {
           public void rm() { ... }
       }
       public void tm() { ... }
   }
}
public team class Team1 extends Team0 {
   protected team class InnerTeamA {
       protected class Role {
           public void rm() { ... }
       }
       public void tm() { ... }
   }
   protected team class InnerTeamB extends InnerTeamA {
       // details inherited from Team1.InnerTeamA and Team0.InnerTeamB
   }
}

• Team1.InnerTeamA.tm()
• Team0.InnerTeamB.tm(),

• Team1.InnerTeamA.Role.rm()
• Team0.InnerTeamB.Role.rm(),

Avoid role cache
since 0.8.0M6
338582

It has been observed that maintaining a large number of roles in the team's internal cache may have significant impact on program performance (observed at 100000 roles of one particular type). A new means for fine tuning has been added for situations where role identity is irrelevant. A role class may now be marked with @Instantiation(ALWAYS) meaning that each lifting operation for this role class will immediately create a new role instance without consulting the role cache. In fact such roles will never be stored in any internal cache. Please read the implications discussed in OTJLD §2.3.1(d).

Dealing with lifting problems
since 2.0RC1
337413

Whenever lifting fails (due to a role binding ambiguity or an abstract relevant role) a LiftingFailedException is thrown from the Object Teams runtime. This exception has now been changed to a checked exception to alert clients of problematic code of the chance of failure. The consequences are defined in the new section OTJLD §2.3.5.

The compiler now has two general ways to signal lifting problems:

• Unhandled exception LiftingFailedException
• Unsafe callin mapping, because lifting to role {0} may fail due to ...

Application code with lifting problems may choose from different strategies:

• Avoid abstractness for bound roles:
  • Add method bodies which log the problem.
    Benefit: unexpected situations will actually be detected.
  • Remove abstract methods and require clients to cast to a specific role type.
    Benefit: client is now clearly repsonsible for dealing with potential ClassCastException in cases where lifting produces an unexpected result.
• Team methods with declared lifting may choose to declare LiftingFailedException
  Benefit: client is alerted of the chance of failure, must handle unexpected situations.
• Callin bindings with unsafe lifting may in special situations pass through using @SuppressWarnings("hidden-lifting-problem")
  Benefit: owner of the role has to explicitly assert that s/he is aware of the chance that the callin binding will not fire due to a lifting problem.
• Revise the role hierarchy to avoid abstract relevant roles and potential binding ambiguities.

Compiler

Severity of write decapsulation
since 0.8.0M5
335523

When a role uses a callout set to field with decapsulation this may be considered more severe than a corresponding get access. Therefor, the compiler now supports separate configurability for both kinds of problems.