The Object Teams Blog

Adding team spirit to your objects.

Object Teams says: “Hello Eclipse”

with 7 comments

I’d like to return the warm “welcome” Wayne recently pronounced under “Heady Times”.
The Object Teams Project is thrilled to finally move into the Eclipse house. I guess we are not complete strangers, as I’ve spoken at two EclipseCons and met quite a few of you in bugzilla etc. But still a majority might not be sure what the Object Teams Project is all about, so here comes a little introduction:

Object Teams banner


Formally, the Object Teams Project is a cross-over between ambitious research in language design and an extremely pragmatic approach to writing highly modular code even under high pressure of re-use, maintenance, evolution and that sort of conditions. Our pragmatism made us refrain from designing a language from scratch but made us create OT/J as an extension of Java. This pragmatism has furthermore led us to spending >99% of our time on building actual working tools in contrast to <1% of tweaking new language features. That’s why we decided as early as 2003 to not develop a standalone compiler for our language but to base everything on the JDT (v2.1.1!) so we would soon have a full-featured, high-quality IDE. From this the Object Teams Development Tooling (OTDT) was born
which had its first public appearance in 2005. This development was a tremendous joint effort (2003-2006) of the Fraunhofer FIRST institute and the Technical University Berlin.

Two ways of looking at Object Teams

(1) Conceptually: Object Teams solves the dilemma of structuring software by functions (procedural or functional approaches) or by data (object oriented approach). In Object Teams you do both simultaneously. Suppose you are writing a banking application. After some core concepts have been implemented and tested you are about to implement a new use case, say Wire-Transfer. Do you add new methods to existing classes like Customer, Account, ATM etc? Or do you consider those classes as dumb data objects and create one new class WireTransfer? The Object Teams answer: you do the best of both approaches: you create a role for each relevant class, implement the new behaviour in terms of role methods calling each other. Roles are grouped into a team (here: WireTransfer) and roles are bound to the underlying core objects (here: of type Customer, Account etc.). – Looking for a data-module, an entity? Just inspect the
Account together with all its roles. – Looking for a behavioral module? Just inspect the WireTransfer team with all its contained roles. Voila.

Sounds esoteric? “Role modeling”, “collaboration based design” and similar off-springs of the same ideas have been embraced for analysis and design for quite some time (cf. OOram, Catalysis etc.). Object Teams finally gives a natural implementation to such models. Finally we can cleanly compose a system from one module per use case.

It turns out, however, that you may also look at Object Teams from an even more pragmatic point of view:

(2) Pragmatically: As one of its core capabilities a role can override a method of its bound base. Given that roles can be added to existing entities at any time (add role classes at compile-time, add role instances to base instances even at run-time), roles provide a mechanism for extending and adapting existing things without touching them (“non-invasively”). As an example consider the JDT/UI: a plug-in providing an excellent user experience for working with Java code. Guess what: just by adding a number of roles and without changing a single source line of the the JDT/UI we created the OTDT/UI: a plug-ing providing an excellent user experience for working with OT/J code 🙂 .

While the mere possibility to non-invasively adapt existing plug-ins is fascinating by itself, using Object Teams for this task also guides you towards a code structure that is actually easy to read and highly suitable for future maintenance and evolution.


Here is why all this is highly relevant for everyone writing Eclipse plug-ins: we have married OT/J to Equinox (first presented at Eclipse Technology eXchange 2006 in Nantes) so that all the concepts of Object Teams can seamlessly be leveraged when developing plug-ins. The consequences of this I will leave for your imagination at this point. More to follow soon.

Show me the code

This post has become a little verbose, with no real examples. Some examples will follow in subsequent posts. In the meantime you may want to look at the

What’s next?

Currently our initial contribution awaits the initial OK so that we can start committing to SVN. Pretty soon after you should expect the first milestone release (incubation) from “If all goes well” we will apply for graduation by the time of the Helios release, so you would see an OTDT 2.0.0 accompanying the Helios GA. After 70+ releases (incl. milestones) in our previous identity at I say we should be able to demonstrate the maturity required for that next big step.

Please stay tuned and join the discussion in our forum.

Thanks to everybody who made our move to possible!


Written by Stephan Herrmann

February 10, 2010 at 17:07

7 Responses

Subscribe to comments with RSS.

  1. Hello Object Teams! Frankly, in that programming context OT/J was one of the things I’ve gotten to know in the last years which really impressed me most. I’m looking forward using OT!

    Jens v.P.

    February 10, 2010 at 21:03

  2. Welcome to the Eclipse community guys. Sorry for the bumpy ride in the beginning but now I hope it’s smooth sailing from now on.

    Chris Aniszczyk

    February 10, 2010 at 21:44

  3. Stephan, congratulations for moving OT under the Eclipse umbrella!


    February 10, 2010 at 22:08

  4. @Jens: Be our guest! I’m looking forward to your questions in our forum.

    @Chris: With your ultra-short response times I had no problems with any of the bumps. Thanks for all your help! You earned yourself a free seating in an OT-tutorial deluxe 🙂

    @Florian: long time no see, but here we meet!


    February 10, 2010 at 22:45

  5. Hi Stephen,

    Very interesting concept !

    Still, i fail to see the distinction between OT,AOP and delegation.
    The three of them are used to separate concerns of a related object.
    How would you compare OT to the two other solutions in term of dynamism, coupling and separation of concern ?
    Thanks in advance,


    Alexandre Mazari

    February 12, 2010 at 10:37

  6. @Alex: Thanks for asking. Maybe that’s too big a question to answer in a comment, so I should actually write a new post exactly to that question.

    When you say “delegation” do you think of what happens in many design patterns like Decorator – something that can easily be done in plain Java? Or are you thinking of delegation as a language concept like in Self[1]? The latter supports overriding in a full template-and-hook style, the former does not.

    Here’s a teaser of my upcoming post then:
    OT, AOP and delegation were developed from clearly different starting points, roughly sketched as:
    OT: more powerful modules
    AOP: better handle crosscutting concerns
    Delegation: decompose behavior
    It happens that the design issues tackled by these approaches overlap to some (small) extent, but that says nothing about the respective core concepts.

    Comparing approaches “in terms of dynamism, coupling and separation of concerns” is a big task. I’ll try to cover that in my post. Certainly all approaches *indend* to by dynamic, support losely coupled designs with excellent separation of concerns. The proof of the pudding is in the eating, but I will give some hints on different priorities among goals.

    Actually, dynamism is again a very broad term. Let me just add as an anecdote that at the times of AspectJ 0.6.x I was urging the AspectJ folks to make aspect instances more first-class with better options to programmatically (un)register and/or (de)activate an aspect instance. They decided not to walk that road. While I’d say they lost dynamism, they surely have a different interpretation of dynamism, for which they probably have strong support. Ask them.

    Positively speaking: the design of OT/J paid very close attention to what’s already there in Java, be not disruptive, rather strengthen existing concepts than introducing entirely new concepts. Given that we know how to construct an object, the main focus was and is: how do we compose a modular, evolvable system from all those objects? How can this composition be specified in the source code? Flexibly, precisely, succinctly, unambiguously, scalably,,…

    Once more: thanks for asking.


    February 12, 2010 at 14:28

  7. […] In response to our “Hello Eclipse” I was asked about “the distinction between OT, AOP and delegation” […]

    Compare Object Teams to AOP?

    February 13, 2010 at 23:38

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: