The release 2.5 is based on Eclipse SDK 4.6 (Neon).
The OTDT contains a modified version of the JDT core and several added plugins.


The following components are available:

Compiler

The Object Teams Compiler is an incremental compiler, based on the Eclipse Compiler for Java. As of version 2.5 the compiler supports all features of Java™ 8.
Language Definition
The compiler implements the language as defined in the OT/J language definition version 1.3.1 (OTJLD). The language definition has continuously been revised to precisely specify the language including various corner cases and combinations of features.
Language Implementation
The compiler supports all features of OT/J according to the otjld OTJLD v1.3.1 §§1-7,9. Support for the join point sub-language (otjld OTJLD § 8) is not included.

The compiler can be configured using global Preferences or project specific Properties.
  • Configure OT/J-specific compiler diagnostics as "ignore", "info", "warning" or "error".
    Any warnings configured on this property sheet can also be suppressed in the source code using the @SuppressWarnings annotation.
  • Scoped keywords otjld OTJLD § A.0.1 can be disabled (default is enabled).
  • The target weaving scheme can be selected during project creation.

Wizards

Editor

Binding Editor

The binding editor can be opened either from the new team wizard or using the package explore's context menu ( Open Binding Editor).

Refactoring

Significant work has been put into supporting the automated refactoring of OT/J code. The following refactorings take into account the Object Teams-specific relationships (implicit role inheritance, team nesting, role-base bindings and method bindings). Additionally, specific refactorings for OT/J are being developed. Currently these are implemented:

Structure Viewers

The Package Explorer
  • provides access to all project artifacts and their structure, i.e. source files, used libraries (jar-files), and other documents. Note that team and role classes are annotated with distinct icons ( for teams and for roles). (The same icons are used throughout the IDE, whenever a team or role is visible.)
  • If "Java Type Indicators" is enabled under general preferences/label decorations, OT-specific decorations will also be applied to compilation units (files) and team packages.
  • By opening the tree-branches, you can peek at the structure of e.g. classes.
  • For team classes, there is special support for role files ( OTJLD § 1.2.5):
    Role files are separate files and can be shown either physically () as (separate) files in the team package or logically () as member types of the enclosing team.
  • Furthermore, the Package Explorer provides the current context for other operations. The Team- and Role-Wizards, for example, have a pre-set source folder, package and enclosing class when a team is selected in the Package Explorer.
The Hierarchy View
  • Object Teams intruduce a new type hierarchy. Besides the normal ("extends") inheritance, there is an additional "implicit" role inheritance, established by role name equality in a team hierarchy. In conjunction with team nesting roles support a controlled form of multiple inheritance.
  • The new implicit inheritance has been integrated completely into the standard JDT Hierarchy View.
Java Structure Compare
  • When comparing versions of an OT/J file, the Java Structure Compare will correctly render Object Teams elements, too.
  • When selecting a callin replace binding, an action "Compare With > Bound Base Method" is available via the context menu, which easily let's you compare the method implementations of role and base.

Search references
  • The Java Search functionality has been extended to include search results of Object Teams code, that is, callin and callout bindings, and playedBy-relationships.
Call hierarchy
  • Also the call hierarchy has been extended for browsing control flows passing through method bindings (callin and callout).
  • The OTDT introduced support for call hierarchies regarding field accesses (read, write, any) and class instantiations. As of version 3.4 this functionality has been adopted by Eclipse.
  • OT/J constructs that may cause role creation due to lifting are considered by the call hierarchy as calling the role's lifting constructor.

Execution Environment

Aspect weaving
  • All aspect oriented languages have some kind of weaving process, where the aspect code is combined with the other (base) code.
  • Object Teams programs perform the weaving at application startup time, i.e. at the moment, the program is launched. In order to do this, there is the so-called Object Teams Runtime Environment (OTRE), that hooks into the class-loading process.
  • All this is handled transparently using the standard Eclipse "Run" feature. Running any main class of an Object Teams project automatically includes the OTRE (This feature has been changed in the OTDT 1.2.2).
Weaving schemes
  • Since version 2.3, the OTDT ships with two distinct weavers with the properties mentioned below. Since the OT/J compiler performs some preparation for the respective weaver, it has to generate different byte code formats, depending on the targeted weaving scheme. As a result, switching from one weaving scheme to the other requires a full recompilation of all OT/J code involved.
    • OTRE: This is the traditional load-time weaver. This weaver has matured over many years, but unfortunately, the underlying library BCEL is no longer maintained and thus cannot handle class files from recent Java versions. Up-to Java 7 this could be worked around, but Java 8 class files contain several elements that this BCEL-based weaver cannot handle.
    • OTDRE: The newer Object Teams Dynamic Runtime Environment has been developed to enable even runtime weaving. To work around limitations of the JVM this weaver has to insert a few general hooks into every weavable class. This weaver is also interesting for weaving into Java 8 class files, as it is based on the library ASM, for which a Java-8-enabled version already exists.
Aspect deployment/activation
  • A new "Team Activation" tab in the "Run-Configuration" allows to instantiate and activate teams without modifying the program's source code.
  • Teams that cause aspect code to be woven into an application can be added to a program
    • by explicit reference within the program source code or
    • by a configuration file which is mentioned as a parameter to the VM or
    • by adding them via the aforementioned "Team Activation" tab.
    No such configuration is needed for compilation.
Technology used
  • Integrating the weaver into the JVM leverages the Java-agent concept of Java 5 (JPLIS).

OT/Equinox

Starting with the OTDT version 0.9.9 (2006) it is possible to develop Eclipse plugins using OT/J as the implementation language.

Debugging

The debugger has been enhanced to support debugging of OT/J programs at the source code level. It is possible to set breakpoints and step through Object Teams code.
Stepping through Code
The following language features produce byte codes for which a standard Java debugger is not able to display appropriate source locations: The OTDT-Debugger re-maps the byte codes produced by all this constructs to the appropriate source locations. As a result stepping through these sections of a program completely hides the internal translations from the user.

The following features are not yet fully supported by the debugger:
Setting Breakpoints
Use double click on ruler or context menu Toggle Breakpoint to set breakpoints in OT/J-Code. Setting breakpoint in role files is supported, too.
New View: "Team Monitor"
The team monitor () view helps to debug issues related to team activation ( OTJLD § 5). For this purpose it displays all known team instances and shows their activation status as one of
  • inactive ,
  • active (either globally or for the thread selected in the debug view), or
  • implicitly active (temporarily active because the team or one of its roles is currently executing code).
Also, a selected team can be (de)activated interactively via the context menu.
Filtering variables
The OT/J compiler and the loadtime weaver both add some internal variables to the code. By default such internal variables are hidden within the Team Monitor as well as in the standard variables view. Both views can be configured to also show these internal variables if so desired.
Known Issues and Limitations
  • Dynamic code evaluation is not supported yet, make sure to clear the Expression view.
  • Stepping through callin bindings under weaving scheme OTDRE is not yet able to always show the correct source code location and shows more hops through generated dispatch code.

Help and additional Information

The following sources for help and for further information are bundled with the release: