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.
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 Object Teams approach has been materialized at two levels.
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.
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.
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.
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:
Back to the top