Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search


The programming language OT/J implements the programming model Object Teams for the host language Java.

Why Object Teams?

Team spirit for your objects

Building complex systems from isolated objects often yields poor structure which readily decays during system evolution. Objects should team-up in order to co-operate and jointly deliver complex behaviors. Objects play specific roles within a given Team.

Context based dispatch

Role instances are attached as specializers to existing objects. Object behavior is controlled by the currently active context that determines which roles are active at a given point in time. Contexts are reified into team instances, which may further be used to mediate between roles and maintain state of the collaboration.

Modules larger than classes

On the road to re-use of modules larger than classes two approaches compete: frameworks and components. For many applications white box frameworks are too fragile and black box components too rigid. Object Teams provide a middle road which balances encapsulation and adaptability.

OT/J Language Definition (OTJLD)

First Reading



OT/J is compiled by a modified version of the Eclipse compiler for Java. This means that the OT/J compiler can also compile any Java program. While OT/J introduces some new keywords most of these words are still treated as normal identifiers until the keyword team has been parsed (OTJLD §A.0.1 -- "scoped keywords"). This provides the greatest possible compatibility at the syntax level.
Compiler invocation
The compiler can be invoked either from the ObjectTeamsDevelopmentTooling (OTDT) or as a command line compiler (ecotj).

For compiling OT/J source outside Eclipse please see either of:

Compiler output
The compiler produces regular Java .class files, which are enriched with OT/J specific meta data using Java bytecode attributes. These meta data are interpreted by the OTRE (see below) in order to weave playedBy and callin bindings into base classes. This implies that OT/J programs need to be launched with the OTRE enabled. Other than that any recent JVM (≥1.5) can be used.

Object Teams Runtime Environment (OTRE)

As mentioned, running an OT/J application requires the OTRE. Currently two alternative modes are supported how the OTRE can be linked into an OT/J application:

  • JPLIS:
This technology is part of the Java standard since version 1.5. Launching an application in JPLIS mode only requires a few items added to the classpath and an -javaagent:... argument, which means a non-invasive way of launching OT/J programs like plain Java programs.
By integration of OT/J with the Equinox component framework, also Eclipse plug-ins (RCP, OSGi bundles) can leverage OT/J. In this case running OT/J code only requires to have the OT/Equinox feature installed on top of Equinox.

Within the OTDT the OTRE is enabled by a new checkbox adjacent to the JRE configuration (see the user guide).

Weaving into system classes

In contrast to an earlier architecture in JPLIS mode the OTRE can weave into more classes, i.e., even system classes from Java's rt.jar can potentially be bound as base classes (note, that any classes loaded before the OTRE starts operation can still not be woven).

Launching from the command line

For running OT/J applications outside Eclipse please see OTHowtos/Running From Commandline.

Build-time weaving

While load-time weaving has the advantage of easier deployment - no tweaking of the classpath is required to ensure that the right version of a class is loaded - it may be difficult to integrate in some application containers. As a fallback mechanism, the OT weaver can be used to process all affected classes already at build-time. The resulting woven classes can then be executed on any JVM (≥1.5) without using the load-time weaver.

Back to the top