A use case for Java 7
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:
And this is what the quickfix would create:
Sounds cool?
The Object Teams Blog 
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…
sp8472
June 14, 2011 at 18:05
@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?
stephan
June 14, 2011 at 18:27
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
@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.
stephan
June 14, 2011 at 19:12
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
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.
stephan
June 14, 2011 at 23:15
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
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.
stephan
June 14, 2011 at 23:42
“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.
stephan
June 14, 2011 at 23:51
[…] 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 […]
Help the JDT Compiler helping you! - 1: Resource Leaks at The Object Teams Blog
January 26, 2012 at 15:32