The Object Teams Blog

Adding team spirit to your objects.

Posts Tagged ‘Java7

“OT/J 7”

leave a comment »

In my previous post I wrote about the challenge of maintaining 12 variants of the JDT/Core to support any combination of Java 6 vs. 7, Java vs. OT/J, with or without support for null annotations at versions Indigo GA, SR1 and Juno M1.

Meanwhile I played a bit with the combination of OT/J with Java 7. While I’m not that excited about Java 7 I found a way to combine the two that I found quite cute.

The typical OT/J foo-bar story

Consider the following classes:

public class Foo {
    public void foo() { System.out.println("foo"); }
}
public team class MyTeam {
    protected class R playedBy Foo {
        callin void bar() { System.out.println("bar"); }
        bar <- replace foo;
    }
}
 

So, we can use the team to replace the output “foo” by the output “bar”.
Now, a client calls f.foo() every now and then and may want to use the team to turn just one of the foos into bar. He may try this:

    public static void main(String[] args) {
        Foo f = new Foo();
        f.foo();
        test(f);
        f.foo();
    }
    static void test(Foo f) {
        MyTeam aTeam = new MyTeam();
        aTeam.activate();
        f.foo();
    }
 

He may expect this output:

foo
bar
foo

BUT, that’s not what he gets: the team remains active and we’ll see

foo
bar
bar

BUMMER.

What is a resource?

I kind-of like the new try-with-resources construct, so what can we actually use it for, is it just for FileReaders and things like that?

Since a resource is anything that is a subtype of AutoCloseable we can use the concept for anything that has an open-close lifecycle. So, what about — teams? Well, teams don’t have open() and close() methods, but isn’t team activation related? Activation opens a context and deactivation closes the context, no?

Let’s turn the team into an AutoCloseable:

public team class MyTeam implements AutoCloseable {
    // role R as before ...
 
    /** Just a simple factory method for active teams. */
    public static MyTeam createActiveTeam() {
        MyTeam t = new MyTeam();
        t.activate();
        return t;
    }
 
    @Override
    public void close() { // please don't throw anything here, it spoils the whole story!
        deactivate();
    }
}
 

Compiler-guided development

Before jumping at the solution, let me show you, what the new warning from Bug 349326 will tell you:

Ah, this is when our developer wakes up: “I might have to close that thing, good, I’m smart enough to do that”. Unfortunately, our developer is too smart, relying on some magic of the hashCode of his Foo:

You imagine, that now the full power of the compiler’s flow analysis will watch whether the thing is really closed on every path!

But even when the dev stops trying to outsmart the compiler, the compiler isn’t 100% happy:

We see the desired output now, but the method can and probably should still be improved: tell us what you mean: are these just three independent method calls? No, lines 1 and 3 are intended as a bracket for line 2: only within this context should aTeam affect the behavior of f.

Here’s our brave new OT/J 7 world:

Method test2() normally behaves identical to test1(), but we have two important differences:

  • test2() is safe against exceptions, the team will always be deactivated
  • test2() makes the intention explicit: the try () { } construct is not only a lexical block, but also a well defined semantic context: telling us that only inside this context aTeam is open/active, and outside it’s not. We don’t need to sequentially read the statements of the method to learn this.

An essential extension

Following my argumentation, OT/J must have been waiting for this language extension for a long time, no? Well, not exactly waiting. In fact, here’s something we had from the very beginning almost a decade ago:

But still, it’s nice to see that now every developer can achieve the same effect for different applications, beyond input streams and teams 🙂

Here’s an exercise for the reader: the within construct in OT/J activates the team only for the current thread. With try-with-resources you can easily setup a context for global team activation and deactivation.

Happy hacking!

Written by Stephan Herrmann

August 25, 2011 at 18:32

Posted in Eclipse, Object Teams

Tagged with , , , ,

A use case for Java 7

with 10 comments

Recent stress tests have revealed a few issues in the Eclipse platform where leaking file handles could cause “Too many open files”-style failures.

Until now that kind of issue was notoriously difficult to analyze, and a lot of luck was involved when I spotted one of those bugs by mere code inspection.

However, chances are that this particular kind of bug will soon be a curiosity from the past. How? Java 7 brings a new feature that should be used in exactly this kind of situation: by the new try-with-resources construct leaking of any resources can be safely avoided.

Now, current code certainly doesn’t use try-with-resources, how can we efficiently migrate existing code to using this new feature? As one step I just filed this RFE for a new warning where try-with-resources should probably be used but is not. At this point I can’t promise that we’ll be able to implement the new warning in a useful way, i.e., without too many false positives, but it sounds like a promising task, doesn’t it?

Here’s a mockup of what I’m thinking of:

Warning: potential resource leak

And this is what the quickfix would create:
After applying the quickfix

Sounds cool?

Written by Stephan Herrmann

June 14, 2011 at 17:11

Posted in Eclipse

Tagged with , , ,