Possible FileHandle leak in BenchmarkGenerator

[Alex Blewitt]

> On 2 May 2016, at 21:04, Alex Blewitt <alex.blewitt at gmail.com> wrote:
> 
>> On 2 May 2016, at 12:51, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
>> 
>> Hi Alex,
>> 
>>> On 05/02/2016 01:42 AM, Alex Blewitt wrote:
>>> 1. Is my understanding on the right lines for how it works and how a
>>> leak may occur?
>> 
>> Yes, we are apparently leaking the PrintWriter there.
>> 
>>> 2. Should I create a bug, and if so, where?
>> 
>> Created one for you:
>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901666
> 
> Thanks!
> 
>>> 3. Should I contribute a fix, and if so, how?
>> 
>> Not this one, but I would appreciate if you can review/test the
>> candidate fix, see the bug comments. (I'd use try-with-resources, but
>> our codebase is still at Java 6).
> 
> I’d have preferred keeping the parameter name as ‘destination’ instead of ‘dest’, unless you’re trying to fit into a line limit somewhere on the generated method. Otherwise looks like it should work. I will do a build on a Windows box in the next day or so and let you know if this resolves the issue I was seeing with annotation processing via Eclipse.

I tested the fix - it's necessary but not sufficient as there is a similar file leak for the same named file in the Reader in the complete method above as well. Once I patched that in a similar way using a try/finally and the safe close from FileUtils it worked. 

I found how to reproduce the issue reliably as well: with m2e and m2e-apt installed and configured to use APT in JDT, and the project updated (so that the annotation processor is configured in Eclipse, adding a benchmark and then commenting it out is enough to leak a handle and the Maven clean fails. With the fixes for both reader and writer it no longer falls to clean with Maven externally. 

Alex