TNBT – Object Teams

15. March, 2011

Object Teams, or OT/J for short, is a solution for the old Java problem “there is no I in ‘team'”: Most Java code is written as if the whole world was openly hostile. It’s riddled with final, private static, singletons, thousands of lines of code which almost do what you need except for this one line .. that you can’t change without copying the other 999.

Groovy’s solution: AST transformation. A topic for another post.

OT’s solution: create a Java-like programming language which allows you to extend code that isn’t meant to. A great example: Extending Eclipse’s Java compiler.

The Eclipse Java compiler is one of the most complex pieces of code in Eclipse (“5 Mbytes of source spread over 323 classes in 13 packages“). Unlike other compilers, it can compile broken code. The same technology is used to create byte code and error markers in the editor.

Stephan Herrmann wanted to add support for @NonNull and @Nullable. Usually, you’d create a branch, keep that branch in sync with the main branch, etc. Tedious. For every change that someone makes in the main branch, you must update your development branch. Even if the change is completely unrelated. CVS has a very limited concept of “related”. DVCS like Git or Mercurial are better at merging but they also don’t understand enough of Java to give the word “related” a useful meaning. “Same file” is the best you can get.

So instead of the tedious way, he used OT/J to create an OT/Equinox plug-in which patches the JDT compiler byte code. Sounds dangerous? Well, OT/J does all the ugly work. You just say “when this method is called, do this, too.” Sounds a bit like AOP? Yes.

Unlike AOP, it communicates intent more clearly. The code wasn’t designed to be the most compact way to define a “point cut” and then leave it to the reader to understand what this is supposed to mean. It better communicates the intent.

I’m not completely happy with the syntax, though. I don’t have specific points, only a general wariness. Maybe a careful application of Xtext would help.

Related Articles:

  • The Next Best Thing – Series in my blog where I dream about the future of software development

Leave a Comment » | Software | Tagged: , , , , , , , , | Permalink
Posted by digulla

When inheritance is not enough

16. September, 2010

Ever had the problem that inheritance just wasn’t enough? For example in this case:

package core;
public class Main {
    public static void main(String[] args) {
        sayHello();
    }
    private static void sayHello() {
        System.out.println("Hello World!");
    }
}

Say you need to override sayHello(). What are your options?

You could edit the source. But if you only have the bytecode?

You could decompile the bytecode. But what if you need the same change in several places?

Eventually, you’ll have to use copy more or less code around because Java just doesn’t offer enough ways to combine code. The solution? Object Teams. See this article for a solution of the problem above.

What is Object Teams?

In a nutshell, a team is a group of players which have roles. Usually, the roles are distributed by way of the strengths of your players. Slow and sturdy ones will be defense. Quick and agile players will attack. The calm ones will do tactics.

OT/J (the Java implementation of Object Teams) does just that: You define teams and roles and then apply those to existing Java code. Let’s take the Observer pattern (you know that design patterns are workarounds for flaws in the language’s design, yes?).

The problem with this pattern is that you can’t apply it retroactively. You must modify the involved classes to support the pattern even if they couldn’t care less. That leads to a lot of problems. Classes which don’t need it must still allocate resources for it. It clutters the API. You can’t add it to classes which don’t support it. If a class only allows you to observe some behavior, you can’t change that.

OT/J fixes all that. The OTExample Observer shows three classes which could make use of the Observer pattern but don’t. Instead, the pattern is retrofitted in all the places where it’s necessary. This allows for many optimizations. For example, you can create a single store for all your observers (instead of one per instance). The API isn’t cluttered. You can observe almost any change.

Leave a Comment » | Software | Tagged: , , , , | Permalink
Posted by digulla

OO 2.0: Reuse

25. February, 2010

What’s the most important feature of OO? Reuse.

What’s the biggest problem of Java? Reuse.

In Java, it’s considered good practice to make everything private or even final. This goes along the lines “when I open part of my API, someone might use it and this might cause problems for me later when I have to change the API”. So all fields are private. Which leads to huge lists of getters and setters which you don’t need most of the time. But you can’t omit them because if you need them, you can’t retrofit them. I guess all of us have a story where we wanted to use a class and everything was fine until we needed one more thing from that class and that thing wasn’t public or protected.

The underlying problem is that Java is based on the idea that the code is simple to parse and read. Which means that things like templates, patterns or pre-compilers aren’t supported. Even when you use annotations, you can’t modify the output at compile time. You can use load time byte-code manipulation but at compile time, the code is about as flexible as a bridge pillar.

But there is hope. The guys from the Object Teams project (OT) have created a Java-like language where you can reach into existing code and manipulate it in various ways. If you’re wondering if this is AOP with a new name or just delegation on steroids, this post will help to understand what OT is and what it’s not.

In a nutshell, OT is about reuse. If some class doesn’t provide a getter for a private field, OT can insert one for you. To get a feeling if OT can help you, I suggest to browse the blog and the examples. The stop watch example is probably the most simple to understand. The other examples look a bit incomplete or they might show that OT still has some issues with the syntax (which you’ll remember from AOP but it’s certainly not as extreme).

I, for one, will keep an eye on this project.

2 Comments | Software | Tagged: , , , , , , | Permalink
Posted by digulla

%d bloggers like this: