java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

My application was running out of file handles. I traced the problem back to a
RandomAccessFile that was not closed during each iteration. The problem was
hard to find because I have a lot of classes made by different persons. What
would be of tremendous use to me :
When RandomAccessFile (and the other related classes) objects are garbage-
collected, can they report, to System.err for example, that a file-handle that
they use is not closed ? If the filename was included in the message, it would
help a lot.
I think that adding the message is necessary because not closing the file
before the  customer  becomes unreachable is an error (which is very hard to find
by the way, because the error only occurs after about 1000 iterations for
example).
By the way, my java application now processes 70 GB of image data in one run
without problems, at a rate of over 12 GB per hour !
(Review ID: 115142) 
======================================================================
Posted Date : 2006-02-08 08:22:09.0

Write custom classes that manage the various file objects, and list their
filenames when problems occur.
======================================================================

Now that we have a real logging facility in 1.4 we should consider doing this
for both java.io streams and java.nio channels.  It's easy to do, and there's
a pretty high payoff, and it's all part of RAS.

--   xxxxx@xxxxx   2001/7/25
It may not be necessary to introduce logging to diagnose file descriptor leaks if changes related to the following jdk7.0 (dolphin) are implemented: 
 
  4171239: File.deleteOnExit() does not work on open files (win32) 
  6322678: FileInputStream(FileDescriptor) throws IOException when 
    reading a file if FD is invalid 
 
The fix for the first bug will track all new FIS, FOS, and RAS objects through a weak ref to the RandomAccessFile.  This should avoid a continuous leak of file descriptors as it polls the reference queue when new streams are created.
 
The fix for the second bug would introduce a reference count on FileDescriptors which would be eligible for gc when the reference count goes to zero.
Posted Date : 2006-02-09 06:18:50.0

The idea behind my request was to give the programmer 
feedback on having unclosed file objects. Closing file 
handles on finalizing -without feedback- will definitly 
make the error harder to find !