Point lambdafications in java.io

[Stephan Herrmann]

>>> I am not sure we have the same understanding of the word "can't" :)
>>> This is definitely a valid concern (thanks for raising it!), but it's
>>> a long way from there to "can't."
>>
>> I you prefer, you can translate "can't" to "It will be very annoying at
>> least 1,643,467 developers*".
>
> Yes, that's a better translation :)
>
> A reasonable course of action here is to work with the IDE vendors on
> this to refine their detectors.  They're even all represented here!

I'm the maintainer of static analysis in the Eclipse compiler and I'm the
author of the particular analysis discussed here.

Brian and I had a brief discussion via email and here's my 2c to add to
the discussion:

In an ideal world (=simple enough to obviously have no errors)
the contract of AutoCloseable would always indicate necessity to close.
Easiest for tools and: easiest for users.

Already in Java 7 static analysis needs to know about several exceptions
in order to be useful in real world use. To accommodate this the Eclipse
compiler already uses three white lists:
- "resource-free" closeables (e.g., ByteArrayInputStream)
- wrapper closeables (e.g., BufferedInputStream)
- 3rd party utilities for closing (e.g., apache's IOUtils.closeQuietly)
And yes, the analysis invests efforts to handle the interactions between
these.

Already at this level it becomes clear that just one interface is not
enough to specify the responsibility to call close(), a JSR 308-based
extended type system is the natural road to capture responsibilities
and effects.

For Java 8, adding one more explicit exception to the leak analysis
is not a big deal. Obviously, completely excluding Stream from this
analysis would be a significant loss in accuracy, not being able to
track, e.g., the GCR resources from Files.walk() would be a pity.
For that reason I strongly suggest to also document the exceptions from
this exception, viz. the API that are known to produce a Stream that
does own one or more GCR resources.
Given this information I can adjust the analysis of the Eclipse compiler
to work well with the Java 8 libraries.

I hope this settles the issue of "can't" concerning static analysis.
I'm not in the position to judge how *users* will find their way to
knowing which AutoCloseables really need closing and which ones don't...

HTH,
Stephan