Name: nt126004			Date: 12/19/2002


FULL PRODUCT VERSION :
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
Contrary to the examples in the New I/O APIs document,
closing a FileChannel does not close the file. Those
examples include code such as the following.

    // Open the file and then get a channel from the stream
    FileInputStream fis = new FileInputStream(f);
    FileChannel fc = fis.getChannel();
    
    // Close the channel and the stream
    fc.close();

This code should actually invoke fis.close(), which would
in fact close both the channel and the stream. This code
example is all the more curious because the
FileChannelImpl class clearly states that FileInputStream,
FileOutputStream, and RandomAccessFile are ?responsible
for closing file descriptor.? For example,

    import java.io.*;
    import java.nio.channels.FileChannel;
    class Test {
       public static void main(String[] args) throws IOException {
          FileOutputStream file = new FileOutputStream("output.txt");
          FileChannel channel = file.getChannel();
          channel.close();
          PrintWriter writer = new PrintWriter(file);
          writer.println("testing, testing, testing");
          writer.close();
       }
    }

This program compiles and writes testing, testing, testing
to the output.txt file, showing that closing a channel
does not close the corresponding file. It is therefore
important to save a reference to the FileInputStream,
FileOutputStream, or RandomAccessFile used to invoke the
getChannel() method (otherwise the file descriptor is not
released).

Here is the site URL with the examples:

http://java.sun.com/j2se/1.4.1/docs/guide/nio/example/index.html

But this is the exact same documentation distributed with the SDK/J2SE.
The problem with only closing the file channel is that it does not
release the file descriptor. I am sure your new I/O guys will concur.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.This is a documentation bug
2.
3.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER WORKAROUND :
this is a documentation bug
(Review ID: 178499) 
======================================================================