Comments on: Help the JDT Compiler helping you! - 1: Resource Leaks

By: Help the JDT Compiler helping you! - 3: The essence of null annotations at The Object Teams Blog

Mon, 05 Mar 2012 19:05:29 +0000

[...] my little excursion to detecting resource leaks let me return to our favorite bug: [...]

By: Help the JDT Compiler helping you! - 2: Resource leaks - continued at The Object Teams Blog

Sat, 04 Feb 2012 20:11:19 +0000

[...] my previous post I showed the basics of a new analysis that I originally introduced in the JDT compiler as of 3.8 M3 [...]

By: stephan

stephan — Sat, 04 Feb 2012 11:18:26 +0000

I added a paragraph for clarification about Buffered* and about the closing of wrapped resources.

Actually, in the example the requested warning against r4 would be useless, because a BufferedReader cannot truncated any file.

In my next post I’ll say more about the balance between reporting everything that looks fishy and being shy regarding any possible false positives.

By: Scott Stanchfield

Scott Stanchfield — Fri, 27 Jan 2012 01:24:30 +0000

While it may not be a resource leak issue, making the distinction in this manner is bound to lead to confusion…

To the user, it seems like the compiler is telling him when he forgot to close a closeable, and they’ll likely think they have the “close” logic proper in that example.

I agree that we can’t catch everything statically, but this seems like you’re making an exception in the more general analysis to rule _out_ a check that would be incredibly helpful.

By: stephan

stephan — Thu, 26 Jan 2012 16:03:15 +0000

@Scott: thanks, that is a very valid point.

However, it is not a point to be considered for leak analysis, or am I missing anything?

We don’t certify correct program behavior, just absence of a very specific kind of problem: resource leaks.

Programs in general are much more complex than any static analysis can digest

OTOH, your comment confirms our strategy to always flag resource problems against the top of a resource wrapper chain.

By: Scott Stanchfield

Scott Stanchfield — Thu, 26 Jan 2012 15:30:41 +0000

Closing wrappers is more complex than you may be thinking. Consider that many wrappers actually buffer content (most obviously the ones that start with “Buffered”)… If you don’t close (or flush) them, the content may not be passed to the wrapped stream.

In your example, anything written to r4 gets buffered before being written to r3. If r4 isn’t flushed or closed, r3 will likely not have received all of the content that was written to r4 (unless the last data written to r4 happens to exactly hit the buffer boundry). Closing r3 effectively truncates the data.

Please rethink the handling of stream decorators like these…