Object Teams (OT)
The project has been created.
The Object Teams Project is a proposed open source project under the Eclipse Tools Project.
This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process document) and is written to declare its intent and scope. This proposal is written to solicit additional participation and input from the Eclipse community. You are invited to comment on and/or join the project. Please send all feedback to the Object Teams forum.
Background and Description
In any software development that involves a certain level of complexity, is based on re-usable components and evolves over a significant period of time, there are typically some tensions between different people and sub-projects contributing to the overall code base. E.g., framework developers have to balance the flexibility of their framework with the safety provided by strong and strictly enforced encapsulation. Framework users (developers of components using the framework) will normally desire more (or just other) options for adapting the framework's behavior than what the framework already provides. Also, different developers may simply focus on different concerns that in the final code crosscut each other due to intricate dependencies. Put simply, these tensions tend to result from the necessity to create systems from a single coherent object oriented design.
In order to overcome much of these tensions the Object Teams (OT) programming model has been developed, which is centrally based on the concepts of roles and teams. Roles have first been introduced for role modeling, where different perspectives are expressed by different models which then relate to a shared set of base abstractions (classes). Roles in Object Teams bring this power of multi-perspective modeling to the level of programming. Each role model is mapped to the implementation as a team class, whose contained roles implement those facets of objects that are relevant to the given perspective. In this approach explicit bindings between a role and its base entity provide powerful means for integrating a system from components. Here integration clearly means more than just creating a system as the sum of its components, but those bindings define significant parts of the communication in the resulting system.
The benefits of developing in the Object Teams approach are twofold:
- The code structure within each component can be much simpler and easier to understand because original concerns can faithfully be encapsulated as teams and roles, allowing for separate evolution of concerns over time. Any crosscutting interaction can concisely be defined using the mentioned bindings.
- Re-use of existing components is greatly improved, because bindings between different components can create client-defined adaptations of a re-usable component in a concise and disciplined way. With Object Teams many of the compromises that are necessary with traditional approaches become obsolete.
The Object Teams approach has been materialized at two levels.
- The programming language OT/J adds the concepts of Object Teams to the Java programming language. Development in OT/J is supported by a comprehensive IDE, the OTDT (Object Teams Development Tooling) , which builds on and extends the Eclipse Java development tools.
Development of the OTDT has started in 2003 (based on Eclipse 2.1.1) to large parts under the umbrella of the publically funded project TOPPrax. After the 1.0 release in March 2007 new release have been published roughly every 6 weeks.
- The component runtime OT/Equinox  extends Equinox as to support so-called aspect bindings accross bundle boundaries. Thus, Equinox bundles (plug-ins) can be implemented in OT/J and explicit bindings connect an Object Teams bundle to other bundles in much more powerful ways than the traditional approach.
OT/Equinox is being developed since 2006 and has been used for the implementation of the OTDT itself ever since.
Proposed ComponentsThe following components define the internal structure of the Object Teams Project, they do not define individual Eclipse projects:
- OT/J. Provides the compiler and runtime for OT/J programs. The compiler can be used as a batch compiler, via Apache Ant or Apache Maven 2 or as part of the OTDT (see below). The OTRE (Object Teams Runtime Environment) consists of a few foundation classes plus a set of byte code transformers that perform the weaving for any role-base bindings.
- OT/Equinox. Provides the runtime for running Equinox bundles written in OT/J. This includes providing an extension point by which aspect bindings are declared to the framework plus an integration of the OTRE byte code weavers into the Equinox framework.
- OT/JPA. Provides an integration of OT/J and the EclipseLink implementation of the JPA.
- OTDT. Provides comprehensive support for developing OT/J programs. This includes specific views, editors, wizards, content assist and debugging support. The OTDT specifically supports development for the OT/Equinox runtime.
The main focus of the project is to maintain and further improve the technology for developing and executing programs written in OT/J. This includes editing (several views, content assist, refactoring etc.) compiling (batch and incremental) running and debugging.
The language is essentially considered fixed as defined in the OTJLD (OT/J Language Definition) version 1.2, i.e., big changes to the language OT/J are outside the scope of this project. The project should, however, react to small changes in the OTJLD.
Current technology includes integration with the runtimes of Equinox and EclipseLink. Creating similar integrations with other runtimes (like, e.g., servlet engines) could be in the scope of the project, given that sufficient interest is expressed.
Further development tools like a graphic modeler for Object Teams could also be in the scope of this project, again depending on interest expressed.
For executing OT/J programs, which currently involves load-time byte-code weaving, a prototype of an alternative strategy exists that also supports run-time weaving. Maturing this prototype is in the scope of this project.
Integration with more tools (see "Tentative Plan" below) is within the scope of this project, interest provided.
Given the relative maturity of the code contribution, a significant goal behind moving this project to Eclipse lies in more effectively promoting Object Teams and actively building a community. These activities will aim at establishing a long term perspective for the Object Teams technology.
Relationship with other Eclipse Projects
The Object Teams Project is currently the only implementation of the Object Teams approach, so no direct competition or overlap exists.
To a certain degree Object Teams shares motivation and a few core mechanisms with aspect-oriented programming and thus with AspectJ and the AJDT. Historically, within the academic context of the AOSD (Aspect Oriented Software Development) conference series, AspectJ and OT/J were occasionally discussed in a competitive way. However, meanwhile both languages are commonly viewed as complementary: At the core of AspectJ a sophisticated pointcut language has been developed. OT/J uses much simpler and more explicit binding mechanisms. On the other hand OT/J focuses more on providing capabilities for creating modules that can be composed in various ways including nesting, layering and inheritance of complex modules. Apart from a few shared motifs AspectJ and OT/J are very different languages (a full discussion of the differences is beyond the scope of this document), and thus their tools do not overlap.
The current OT/J compiler is a source-level branch of the Eclipse Compiler for Java™ (ecj, part of the JDT/Core). As such it shares all properties like incremental compilation, support for eager parsing, public AST (dom) etc. with the original. The OT/J compiler is compatible with the ecj, as demonstrated by the corresponding JDT test suites. These test suites find no significant differences between the original JDT and the Object Teams variant. Within the source code all additions and modifications are clearly marked (see also the section development). The parallel development of the JDT/Core and the OT/J branch has fostered quite some interaction between developers including numerous contributions to the JDT/Core.
Other parts of Eclipse are re-used and extended/adapted using OT/Equinox: JDT/UI, JDT/Debug (Core and UI), PDE (Core and UI) etc. While adapting these components in unanticipated ways, their source code is not altered. OT/Equinox and the OTDT are very explicit regarding the facts of bundle adaptation, so both developers and users can easily inspect the status of the system using the "About" dialogs, a specific OT/Equinox monitor and the package explorer (during development).
OT/Equinox is also related to the Equinox Aspects project. At some point it might be considered to merge these two efforts. However, currently OT/Equinox has a few requirements (regarding load order and eager activation) that are not covered by the current design of Equinox Aspects. A merger of both projects would facilitate the combined use of OT/Equinox with other components employing a byte code weaver.
Many other projects can potentially benefit from Object Teams. E.g., a case study has shown how the maintainability of a graphical editor based on EMF/GMF can be significantly improved. Regarding the model driven approach it is a well-known problem that many issues of fine-tuning a generated application can best be solved using customizations of the generated source code, which eventually degrades the structure and thus maintainability of the software. The mentioned case study has demonstrated that all customizations of the class diagram editor from the UML2Tools project could effectively be restructured as an OT/Equinox plug-in that is bound to a pristine version of the generated source code. We expect similar scenarios to apply to several other Eclipse projects.
- Subversion source code repository (migrated from an initial CVS repository).
- JUnit plug-in tests: a number of original Eclipse test suites are used (with slight modifications) plus additional 2150 JUnit plug-in tests specific for OTDT features.
- A specific test suite for compiler and runtime comprising currently 2300 test programs.
- Total number of test cases used in daily builds is currently 44520
- Build automation based on PDE-build
- Issue tracking and wiki using Trac
When adapting the JDT/Core great care has been taken in sustaining maintainability. For that purpose a strict discipline of marking code changes has been applied throughout. For all other plug-ins beside the JDT/Core in-place modification has been strictly avoided, but OT/Equinox has been used to integrate any required adaptations. Since its inception we have migrated our branch to a new version of Eclipse for 5 times. By the experience from these migrations, the co-evolution of Eclipse and the OTDT has become routine. Integrating the Object Teams development with the Eclipse coordinated releases will require only minimal changes in our development process.
The initial committers will focus on further improving the compatibility with the JDT, to the end that replacing the JDT/Core with its Object Teams variant has no negative impact on any user in any configuration. Wherever suitable this will include cooperating with other projects, especially the JDT/Core team, in order to help improving the flexibility of those core components.
Also the usage of a few libraries (notably BCEL) will be sorted out as to fit within the Eclipse policies.
- Stephan Herrmann (Independent): Project Lead.
- Marco Mosconi (Fraunhofer FIRST): Committer.
- Olaf Otto (Unic AG): Committer OT/JPA
- Chris Aniszczyk
- Darin Wright
- Ed Merks
Interested partiesThe following companies/projects/individuals have expressed interest in this project. Key contacts listed.
- itemis: Steffen Stundzig
- GEF3D: Jens von Pilgrim
- Intershop Communications AG: Peter Hänsgen
- GEBIT Solutions: Tom Krauss
- BeagleSoft: Tim Ehlers
- Martin Lippert
A new version can be released any time. It is planned that the project graduates in the summer of 2010, so that the official 1.0 release of Object Teams as an Eclipse project shall hopefully be published in conjunction with the Helios coordinated release.
Future plan items include:
- Maturing the JPA integration.
- Potentially integrating with Equinox Aspects.
- Integrating with more tools like Mylyn, EclEmma, TOD, etc.
- Continuous improvement of all existing components.
Current Home PagePlease visit www.objectteams.org for more information.
-  "Plugin reuse and adaptation with Object Teams: Don't settle for a compromise!", presentation by Stephan Herrmann at EclipseCon 2009
-  "The Object Teams Development Tooling: A high fidelity extension of the JDT", presentation by Stephan Herrmann at EclipseCon 2008
-  "Integrating Object Teams and OSGi: Joint Efforts for Superior Modularity", Stephan Herrmann and Marco Mosconi in Journal of Object Technology, vol. 6, no. 9, October 2007, pages 105—125.
-  "Modular EMF/GMF customization with ObjectTeams/Java — case study: UML2 Tool", presentation by Marco Mosconi at Eclipse Demo Camps May/June 2009.