The Object Teams Blog

Adding team spirit to your objects.

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 , , ,

10 Responses

Subscribe to comments with RSS.

  1. And what if you’re reading only part of the output stream, and other clients will read the remainder? Then someone else has the responsibility of closing it… So perhaps this would need a @SuppressWarnings for such cases? Of course, once you add one of those, then it can no longer detect that you actually close it in another client…


    June 14, 2011 at 18:05

  2. @sp8472: First, yes, the ability to use @SuppressWarnings is precondition to making this RFE useful in practise.

    But each time you use @SuppressWarnings it should make you think: I’m leaving the grounds where the compiler can help me. Perhaps I should restructure my code?

    If a reference is handed around to too many folks it’s just as in real life: all responsibility will just diffuse, everybody will expect “someone else” will take care. In this regard too much freedom will get us nowhere.

    So the new construct should actually push you towards a design where for each resource indeed one method is in charge (if this is not already the case). In the RFE I already elaborated a bit on how the analysis could detect, which method this is supposed to be.

    makes sense?


    June 14, 2011 at 18:27

  3. You should also consider running static code anlysis tools like FindBugs. It’ll catch the situations where you are not closing your streams.

    David Carver

    June 14, 2011 at 18:47

  4. @David: You might have noticed: the JDT compiler, too, is a static code analysis tool :), just developed with more emphasis on performance (“performed on each keystroke”) than on completeness of analyses.

    That said: can you report how complete FindBugs is wrt detecting not-closed streams? What if the reference to the stream is shared by many, as sp8472 mentioned?

    My motivation for pushing some of these things into the JDT compiler is twofold: (1) for more immediate feedback, always, without the need to install additional tooling. (2) for optimal integration with quickfixes. This holds for un-closed resources, null-related problems, unused objects and things like that.


    June 14, 2011 at 19:12

  5. It’s pretty complete in detecting the cases. It is a byte code interpreter, but so far every case it has detected for my use cases has been exactly correct.

    Compared to what FindBugs and PMD detect, the JDT compiler is way behind.

    David Carver

    June 14, 2011 at 22:57

  6. Stating that “every case it has detected for my use cases has been exactly correct” doesn’t really say much about completeness 🙂

    OTOH I know that tools specialized just in static analysis can of course detect more problems than a compiler.

    I was just curious to learn *how* much deeper they look. E.g., what if a reference to an InputStream is passed around from one method to another? Normally it would take s.t. like annotations to express which method is responsible. In the academic world people talk of ownership models for expressing things like that.


    June 14, 2011 at 23:15

  7. Best thing to do is contact the main developer on FindBugs and start a dialog there. I know he’s run his tools against the eclipse code base. Also there is a FindBugs plugin that you can use to run it locally within eclipse, so you can do some comparisons that way.

    I would love to see more complete static code anlaysis in eclipse, and in particular known issues turned on by default.

    David Carver

    June 14, 2011 at 23:26

  8. Coming back to the original topic of my post: I think try-with-resources is actually a useful addition to the language, because it helps you to be more explicit by saying: “this block is responsible for the given resources”. This helps connecting intent with enforcement, so we can write better code right away. And the occasion has shown the relevance of this particular kind of problem.

    In this context analysis tools can help us stay on track, no more, no less.


    June 14, 2011 at 23:42

  9. “Best thing to do is contact the main developer on FindBugs and start a dialog there.”

    I tried to contact William Pugh regarding null annotations, but never got an answer. Others have reported the similarly.

    “I would love to see more complete static code anlaysis in eclipse”

    I’m trying to help here and there. Do you have any particular checks in mind? The big rule for JDT is, however, all analyses must be fast and general.

    “and in particular known issues turned on by default.”

    I agree.


    June 14, 2011 at 23:51

  10. […] the JDT team was finishing up work on the new try-with-resources statement introduced in Java 7. So I was thinking: shouldn’t the compiler help users to migrate from notoriously brittle handling of resources […]

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: