code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile

Seán Coffey sean.coffey at oracle.com
Fri Nov 4 13:08:41 UTC 2011


ok,

so updated webrev at : http://cr.openjdk.java.net/~coffeys/webrev.7105952.2/

some minor modifications :

* "closed" variable made private
* hg mv instead of rm/add for testcase
* testcase padded up some more.
* comments changed to block style format in FileDescriptor.
* some extra comments added to FileDescriptor to help read code

I'll leave the javadoc changes for another bugID/CCC request.

regards,
Sean.

On 02/11/11 06:35, Alan Bateman wrote:
> On 01/11/2011 09:47, Seán Coffey wrote:
>> :
>>
>> Are you referring to the parent.close() call ? If otherParents is 
>> null, then we only have one reference to this FileDesriptor - i.e the 
>> Stream that has called close().
> It's parent.close() that I'm wondering about. Suppose p1 is the 
> parent, p2 is in otherParents. If p2.close is invoked then it looks 
> like p1's close method will not be invoked, leaving p1 open and the 
> underlying file descriptor closed.
>
>>
>> Any exception from releaser.close() becomes the main exception if one 
>> is seen there. Any exceptions from the earlier closes are then added 
>> as suppressed. I've run some tests on this and it looked to work as 
>> expected. (stack trace below)
> In this example then the IOException appears to be thrown suppressing 
> one exception. That suppression exception in turn suppresses two 
> others. I had expected that the primary IOException would have 
> suppressed three exceptions. As I said, in practical terms this is 
> much of a concern, just pointing out that it's not exactly as expected.
>
>> I used hg rm/add. I guess hg mv would have worked too.
> You need to use hg mv so that the history can be followed. Also webrev 
> handles it, at least before you create the changeset, so that you can 
> easily see the changes.
>
> -Alan.



More information about the core-libs-dev mailing list