Skip to main content
Jump to: navigation, search


As a central component of the OTDT we are maintaining a branch of the org.eclipse.jdt.core plugin.

This page summarizes background, design rationale and consequences of this branch. It is created as input for bug 330534 where the of including Object Teams in the Indigo release train is discussed.

Extending Java

A large number of research projects over the last decade or so has used Java as a platform for performing research regarding the design of object oriented programming languages. Despite the large number of (prototypical) tools this field is hardly represented at, which means no standard technology and process exists for this kind of project.

Characterizing the Relation between Java and OT/J

Extending Java can mean a lot of different things. Without going too deep into the description of OT/J this specific relation to Java can be characterized as follows:

  • The syntax is extended at several levels:
    • New modifiers like team, callin seamlessly integrate into the existing grammar
    • The new block construct within() {} is syntactilly similar to, e.g., while. It can appear in any location within an OT/J program.
    • A new syntax for type parameters is added (T<@anInstance>), that may occur in any location using type references.
    • Method signatures can, in specific contexts, declare a parameter with two types using the "ARole as ABase param" syntax.
    • Method bindings (callin/callout) introduce new syntax (e.g., "roleMethod -> baseMethod") representing a new kind of class-members.
So essentially the language design by intention creates a new cohesive language rather than two separated sub-languages.
  • Typesystem
    • The introduction of a new kind of type parameter has impact on all aspects of type checking. These parameters can be freely combined with any existing type constructors like arrays and regular type parameters.
  • Inheritance
    • Even without any new syntax a new kind of inheritance relationship is introduced (role classes as inner classes of a team are virtual classes). A role class may override an inherited role class and it implicitly inherits all members of the class it overrides.

Technical implications of the Relation between Java and OT/J

  • Syntax integration:
    • The syntactic integration implies that the resulting language cannot easily be subdivided into two sub-languages that would be parsed by separate parsers with delegation between them two.
    • To achieve greatest possible compatibility, the scanner enables a subset of keywords only after the keyword team has been consumed.
    • Specifically, within and the new type parameters are enabled in all contexts.
    • The scanner has a master switch for disabling even within and special type parameters.
  • Type checking:
    • As type checking in the JDT compiler is essentially performed in resolveType methods of all AST classes, changes in the type system affect most of these plus also the more centralized parts in ClassScope and MethodVerifier, e.g..
  • Inheritance:
    • Since OT/J supports a mild form of multiple inheritance which cannot be accepted by the JVM, prior to code generation this structure has to be flattened somehow. In OT/J this is solved in two steps:
      • role classes are split into an interface part (truthfully modeling the multiple inheritance) and a class part (containing the implementation).
      • implicit inheritance is implemented by copying (and adjusting) bytecodes from a super-role to the sub-role.
    The hidden duality of class and interface parts of the same source-code class is pervasive because (a) type checking requires to operate on the interface part (b) field access requires to switch over to the class part (c) role instantiation requires a hidden redirection to a synthetic creation method instantiating the class part.
  • Compilation order:
    • Due to the invasive nature of some translations the general rule of translating one class at a time had to be abandoned and an explicit state model exists that manages the order of individual translation steps for individual classes (even within the same compilation unit).

Extensible Java IDE

Ideally, generic tooling would be used for adding new language features to Java and extending all of the IDE to reflect the language enhancement. Tools that strive at some sub-goals of this vision include:

  • JastAdd - extensible compiler, not at
  • IMP - meta IDE
  • Xtext - IDEs for DSLs

Ideally, all these projects would join forces with all of JDT to produce an environment that has all the extensibility for creating JDT-quality IDEs for any extensions of Java.

Since this perfect platform hasn't arrived at the train (ups?) for now and the years to come, a different architecture has to be chosen.

OTDT Architecture

The basic idea is to just swap the core component for Java with the extended OT/J variant in order to leverage all tooling that the Eclipse community provides for Java development also for development with OT/J.


This is where the branched variant of the org.eclipse.jdt.core resides. It is based on the original sources of the JDT/Core, with many changes within existing classes and some org.eclipse.objectteams packages for added classes.

  • As of version 3.7M3 / 0.8M3 the diff between the original and the OT branch measures 2.9Mbyte (zipped 550Kbyte). It has been uploaded here.

Upper layers

A few new plugins exist that add a few new views to the IDE and for implementing basic support for binding the OT runtime environment (for compile time and run time) etc.

Developing OT/J code happens through the JDT/UI. This is possible because the JDT/UI talks to the JDT/Core, which in this configuration is the variant with OT-support built in. In a few places the JDT/UI expects to know about all possible AST types, which is no longer true with OT/J. These locations are adapted non-invasively using (internally realized by loadtime bytecode weaving). Additionally, many functions of the JDT/UI (code assist, refactoring ...) have been extended using OT/Equinox in order to provide enhanced support for OT/J. E.g., preconditions of refactorings need to check additional information, quick fixes may offer additional proposals, etc.

The same pattern is applied to plugins like JDT/Debug, JDT/DebugUI, PDE/UI etc.

OTDT Development Process

OTDT Testing

Back to the top