The Object Teams Blog

Adding team spirit to your objects.

Object Teams with Null Annotations

with 5 comments

The recent release of Juno M4 brought an interesting combination: The Object Teams Development Tooling now natively supports annotation-based null analysis for Object Teams (OT/J). How about that? 🙂
NO NPE

The path behind us

Annotation-based null analysis has been added to Eclipse in several stages:

Using OT/J for prototyping
As discussed in this post, OT/J excelled once more in a complex development challenge: it solved the conflict between extremely tight integration and separate development without double maintenance. That part was real fun.
Applying the prototype to numerous platforms
Next I reported that only one binary deployment of the OT/J-based prototype sufficed to upgrade any of 12 different versions of the JDT to support null annotations — looks like a cool product line
Pushing the prototype into the JDT/Core
Next all of the JDT team (Core and UI) invested efforts to make the new feature an integral part of the JDT. Thanks to all for this great collaboration!
Merging the changes into the OTDT
Now, that the new stuff was mixed back into the plain-Java implementation of the JDT, it was no longer applicable to other variants, but the routine merge between JDT/Core HEAD and Object Teams automatically brought it back for us. With the OTDT 2.1 M4, annotation-based null analysis is integral part of the OTDT.

Where we are now

Regarding the JDT, others like Andrey, Deepak and Aysush have beaten me in blogging about the new coolness. It seems the feature even made it to become a top mention of the Eclipse SDK Juno M4. Thanks for spreading the word!

Ah, and thanks to FOSSLC you can now watch my ECE 2011 presentation on this topic.

Two problems of OOP, and their solutions

Now, OT/J with null annotations is indeed an interesting mix, because it solves two inherent problems of object-oriented programming, which couldn’t differ more:

1.: NullPointerException is the most widespread and most embarrassing bug that we produce day after day, again and again. Pushing support for null annotations into the JDT has one major motivation: if you use the JDT but don’t use null annotations you’ll no longer have an excuse. For no good reasons your code will retain these miserable properties:

  • It will throw those embarrassing NPEs.
  • It doesn’t tell the reader about fundamental design decisions: which part of the code is responsible for handling which potential problems?

Why is this problem inherent to OOP? The dangerous operator that causes the exception is this:

right, the tiny little dot. And that happens to be the least dispensable operator in OOP.

2.: Objectivity seems to be a central property on any approach that is based just on Objects. While so many other activities in software engineering are based on the insight that complex problems with many stakeholders involved can best be addressed using perspectives and views etc., OOP forces you to abandon all that: an object is an object is an object. Think of a very simple object: a File. Some part of the application will be interested in the content so it can decode the bytes and do s.t. meaningful with it, another part of the application (maybe an underlying framework) will mainly be interested in the path in the filesystem and how it can be protected against concurrent writing, still other parts don’t care about either but only let you send the thing over the net. By representing the “File” as an object, that object must have all properties that are relevant to any part of the application. It must be openable, lockable and sendable and whatnot. This yields
bloated objects and unnecessary, sometimes daunting dependencies. Inside the object all those different use cases it is involved in can not be separated!

With roles objectivity is replaced by a disciplined form of subjectivity: each part of the application will see the object with exactly those properties it needs, mediated by a specific role. New parts can add new properties to existing objects — but not in the unsafe style of dynamic languages, but strictly typed and checked. What does it mean for practical design challenges? E.g, direct support for feature oriented designs – the direct path to painless product lines etc.

Just like the dot, objectivity seems to be hardcoded into OOP. While null annotations make the dot safe(r), the roles and teams of OT/J add a new dimension to OOP where perspectives can be used directly in the implementation. Maybe it does make sense, to have both capabilities in one language 🙂 although one of them cleans up what should have been sorted out many decades ago while the other opens new doors towards the future of sustainable software designs.

The road ahead

The work on null annotations goes on. What we have in M4 is usable and I can only encourage adopters to start using it right now, but we still have an ambitious goal: eventually, the null analysis shall not only find some NPEs in your program, but eventually the absense of null related errors and warnings shall give the developer the guarantee that this piece of code will never throw NPE at runtime.

What’s missing towards that goal:

  1. Fields: we don’t yet support null annotations for fields. This is next on our plan, but one particular issue will require experimentation and feedback: how do we handle the initialization phase of an object, where fields start as being null? More on that soon.
  2. Libraries: we want to support null specifications for libraries that have no null annotations in their source code.
  3. JSR 308: only with JSR 308 will we be able to annotate all occurrences of types, like, e.g., the element type of a collection (think of List)

Please stay tuned as the feature evolves. Feedback including bug reports is very welcome!

Ah, and one more thing in the future: I finally have the opportunity to work out a cool tutorial with a fellow JDT committer: How To Train the JDT Dragon with Ayushman. Hope to see y’all in Reston!

Advertisements

Written by Stephan Herrmann

December 20, 2011 at 22:32

5 Responses

Subscribe to comments with RSS.

  1. Your integration with equinox is just awesome.

    I am more an eclipse “hacker” than a coder ATM and the fact that we can surround methods of basically any class of any plugin made my day a lot brighter 🙂 .
    I can now deploy a fix easily without having to wait for the fix to be integrated in eclipse: after packaging it in a feature and installing it in a standard untouched eclipse it just works, Thanks for that !

    Do you have any data on the performance hit ?
    I understand that it will be slower when a method is surrounded and I am quite ok with that, but does it slow down significantly the whole calling process when no Role is registered on a class ?

    I now have to dig a little in the Object Teams programming model but it seems to look a lot like Aspect.

    Mathieu Velten

    December 22, 2011 at 17:00

  2. Hi Mathieu,

    thanks for your encouraging comment 🙂

    > Do you have any data on the performance hit ?

    We have done measurements at several levels like: micro benchmarks [1], Eclipse startup time (unpublished), but don’t trust these figures, what really counts is just how *your application* performs with OT/J.

    So if you’re concerned about performance, I think it helps more to understand *what* actually incurs any performance costs.

    > I understand that it will be slower when a method is surrounded and I am quite ok with that, but does it slow down significantly the whole calling process when no Role is registered on a class ?

    A base class that has no role bound to it is totally unaffected. Also, a base method that is not affected by any callin binding is totally unaffected.

    Only if a callin binding exists, two kinds of costs have to be paid: for each base object the first dispatch may need to create a role instance (and store it in internal data structures for house keeping) and each invocation of the bound method naturally requires some lookup and dispatch.

    If your using OT/Equinox you can actually use the “OT/Equinox Monitor” view to inspect the number of roles that have been created on behalf of a given team (just click on a row and wait for the hover).

    In case you should notice a relevant slow down and you know the cause, we do have some tricks for tuning the performance 🙂

    > I now have to dig a little in the Object Teams programming model but it seems to look a lot like Aspect.

    While digging you’re always welcome to ask questions in our forum [2].
    As for a comparison with Aspects, have you seen my earlier post [3] ? Does it answer some of your question? For just a quick hack the conceptual differences may not be extremely relevant, but the more you think of evolving the quick hack to something sustainable, the more you should benefit from Object Teams.
    And mind you: evolving can well mean to transform an OT/J solution back into a plain Java solution, if you must. That’s what I just did with the null annotation prototype: doing the transformation was easy, only, now I miss the wonderful modularity of the solution.

    So my advice typically is: if you use OT/J for some “hacking”, do it with style :), i.e., also the code for the quick adaptation can and should be clean and well-readable code!

    [1] http://www.objectteams.org/publications/index.html#haeder
    [2] http://www.eclipse.org/forums/eclipse.objectteams
    [3] http://blog.objectteams.org/2010/02/compare-object-teams-to-aop/

    stephan

    December 22, 2011 at 17:34

  3. Thanks for the answers.

    I read your blog post and the concepts are more clearer now.

    I am really interesting in the technical details of the weaving implementation on the equinox side. Your first link seems to be really interesting on that according to the schematics unfortunately I can’t read german at all 😦 .

    I guess you are using the loadtime weaving presenting in the paper by patching the bytecode in the ClassLoader to insert hooks to methods that can at least have one role hooking on it : it looks to be the better compromise between perfs (no hit if nothing needs to be hooked on a method, unlike runtime weaving) and ease to use (no modification of the base classes before the execution which is great if we want to hook easily in a library/plugin without modifying it).

    Mathieu Velten

    December 23, 2011 at 11:36

  4. Forgot one question :

    Can you think of any drawback of the needed VM options in the eclipse.ini (except that we need a Sun JVM >= 1.5.0_07, and it shoud not be activated on MacOSX) :
    -XX:+UnlockDiagnosticVMOptions
    -XX:+UnsyncloadClass

    There is not a lot of infos on Google regarding those options…
    I am planning to release the next Topcased with those options so we can deploy easily specific hacks to our clients.

    Thanks.

    Mathieu Velten

    December 23, 2011 at 11:52

  5. @Mathieu: I posted some explanations regarding the VM options in the Object Teams Forum.

    Also: your understanding of our loadtime weaving is correct. Let me know if you specific questions.

    stephan

    December 23, 2011 at 21:46


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: