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

ADDITIONAL OS VERSION INFORMATION :
Windows XP SP1

A DESCRIPTION OF THE PROBLEM :
The method InputStream.read(byte[], int, int) doens't do what is expected, and can hang a thread when the input stream is wrapped into a BufferedInputStream.

BufferedInputStream's fill() method calls read(byte[], int, int) on nested input stream to read up to a max of bytes. However, InputStream's read method doesn't return until "len" bytes are read or end of stream has been reached.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run attached test application.

java InputStreamReadBug -buffered -> hangs
java InputStreamReadBug -> does not hang

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
InputStream.read() should wait for one byte, but not wait for any more data that is not available. If calling read(buf, 0, 5) and only 2 bytes are avaiable, read() shold return two bytes only.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.io.*;

public class InputStreamReadBug extends InputStream {

    byte[] data = { 1, 2, 3, 4, 5};
    int current = 0;
    
    private void waitForever() {
        try {
            Object lock = new Object();
            synchronized (lock) {
                lock.wait();
            }
        }
        catch (InterruptedException ex ){
        }
    }
    
    /**
     * Simulate a socket that has 5 bytes available, reading
     * past that will block on read()
     */
    public int read() {
        if (data.length - current > 0) {
            return data[current++];
        }
        else {
            // no data available, we wait
            waitForever();
            return -1;
        }
    }
    
    public int available() {
        return data.length - current;
    }

    
    public static void main(String[] args) throws Exception {
        
        InputStream x = new InputStreamReadBug();

        if (args.length == 1 && args[0].equals("-buffered")) {
            x = new BufferedInputStream(x);
        }
        
        /* there are 5 bytes available to be read from the
         * input stream, so we should be able to do this
         * WITHOUT BLOCKING
         */
        for (int i=0; i<5; i++) {
            System.out.println("reading byte: " + x.read());
        }
    }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
If you write a class that extends InputStream, overwrite read(buf, off, len). If you don't you run into problems if your stream is wrapped into a BufferedInputStream.
###@###.### 2004-11-09 12:00:00 GMT
Suggested fix contributed by java.net member leouser:

A DESCRIPTION OF THE FIX :
 BUGID: 6192696 BufferedInputStream.read(byte[], int, int) can block if
  the entire buffer can't be filled.
 This appears also to be BUGID: 4479751

FILES AFFECTED: java.io.BufferedInputStream
JDK VERSION: jdk-6-rc-bin-b64-linux-i586-15_dec_2005.bin

Discussion(embeded in test case as well):
/**
 * BUGID: 6192696 BufferedInputStream.read(byte[], int, int) can block if
 * the entire buffer can't be filled.
 * This appears also to be BUGID: 4479751
 *
 * This Bug is about blocking when you shouldn't.  Sounds like something
 * that would happen in a sports game, but here it relates to the BufferedInputStream.
 * The problem stems from the fill method calling the decorated InputStreams
 * read method.  This can block.  'fill' does no checking with the available
 * method of the InputStream.  This in turns can cause this part of the read
 * methods contract that it should not block to be violated.
 *
 * The implementation I have provided to fix this blocking behavior checks
 * the available method, ensuring that a read is only as large as what is
 * available.  This though by itself may be inadequate.  Hence after the
 * read, we check again the amount available.  This process continues
 * until the buffer is full or the InputStream indicates that it doesn't
 * have any data available.  This will ensure the buffer is filled properly
 * if the underlying InputStream makes available more data after it has
 * been read thouroughly.  It also will help emulate the behavior of
 * reading until the buffer is full, if it is possible to fill it up. I guess
 * the design is: keep reading while you can.
 *
 * Another problem that may have been lurking is in the read1 method.
 * In this method there is an unchecked call to InputStream.read.  This
 * could result in the same blocking behavior as we've seen in fill.  Therefor
 * I have enhanced this code to do the read at most with what is available.
 *
 * ANTI-RATIONALE: this may break clients that are relying upon this bug. :D
 * We also are gaining 4-5 lines of code, but this is necessary to ensure
 * the more sophisticated behavior is in place.
 *
 * TESTING STRATEGY:
 * Exercise both read methods and use the custom InputStream as
 * the source of the data.  Since the custom InputStream only will
 * return 1 byte at a time this will test the looping behavior in
 * the fill method.  The fill is indirectly called by testBIS1 and
 * testBIS2.  These tests do not exercise the read1 methods loop.  But
 * upon observation, starting Java instance appears to exercise this
 * loop.  Since this occurs, does successful startup qualify as a test
 * for that piece of code?
 *
 * Files affect: java.io.BufferedInputStream
 * BufferedInputStream enhanced with java 6 version:
 * jdk-6-rc-bin-b64-linux-i586-15_dec_2005.bin
 *
 * test ran succesfully on a SUSE 7.3 Linux distribution
 *
 * Brian Harry
 * ###@###.###
 * Jan 15, 2006
 */

UNIFIED DIFF:
--- /home/nstuff/java6/jdk1.6.0/java/io/BufferedInputStream.java	Thu Dec 15 02:16:35 2005
+++ /home/javarefs/java/io/BufferedInputStream.java	Sun Jan 15 17:04:20 2006
@@ -215,9 +215,16 @@
                 buffer = nbuf;
 	    }
         count = pos;
-	int n = getInIfOpen().read(buffer, pos, buffer.length - pos);
-        if (n > 0)
-            count = n + pos;
+	InputStream ins = getInIfOpen();
+	while(ins.available() > 0  && count != buffer.length){ //read until full or nothing available..
+	    int available = ins.available();
+	    int amount = buffer.length - count;
+	    if(amount > available) amount = available;
+	    int n = ins.read(buffer, count, amount);
+	    if(n > 0)
+		count = n + count;
+        }
+
     }
 
     /**
@@ -251,7 +258,19 @@
 	       bytes into the local buffer.  In this way buffered streams will
 	       cascade harmlessly. */
 	    if (len >= getBufIfOpen().length && markpos < 0) {
-		return getInIfOpen().read(b, off, len);
+		int amount = 0;
+		InputStream ins = getInIfOpen();
+		int spot = off;
+		int tlen = len;
+		while(ins.available() > 0 && amount < len){
+		    int available = ins.available();
+		    if(tlen  > available) tlen = available;
+	            int ramount = ins.read(b, spot, tlen);
+		    amount += ramount;
+		    spot += ramount; //move ahead
+		    tlen = len - ramount; //shrink
+		}
+		return amount;
 	    }
 	    fill();
 	    avail = count - pos;


JUnit TESTCASE :
import junit.framework.TestCase;
import junit.textui.TestRunner;
import static java.lang.System.out;
import java.io.*;

/**
 * BUGID: 6192696 BufferedInputStream.read(byte[], int, int) can block if
 * the entire buffer can't be filled.
 * This appears also to be BUGID: 4479751
 *
 * This Bug is about blocking when you shouldn't.  Sounds like something
 * that would happen in a sports game, but here it relates to the BufferedInputStream.
 * The problem stems from the fill method calling the decorated InputStreams
 * read method.  This can block.  'fill' does no checking with the available
 * method of the InputStream.  This in turns can cause this part of the read
 * methods contract that it should not block to be violated.
 *
 * The implementation I have provided to fix this blocking behavior checks
 * the available method, ensuring that a read is only as large as what is
 * available.  This though by itself may be inadequate.  Hence after the
 * read, we check again the amount available.  This process continues
 * until the buffer is full or the InputStream indicates that it doesn't
 * have any data available.  This will ensure the buffer is filled properly
 * if the underlying InputStream makes available more data after it has
 * been read thouroughly.  It also will help emulate the behavior of
 * reading until the buffer is full, if it is possible to fill it up. I guess
 * the design is: keep reading while you can.
 *
 * Another problem that may have been lurking is in the read1 method.
 * In this method there is an unchecked call to InputStream.read.  This
 * could result in the same blocking behavior as we've seen in fill.  Therefor
 * I have enhanced this code to do the read at most with what is available.
 *
 * ANTI-RATIONALE: this may break clients that are relying upon this bug. :D
 * We also are gaining 4-5 lines of code, but this is necessary to ensure
 * the more sophisticated behavior is in place.
 *
 * TESTING STRATEGY:
 * Exercise both read methods and use the custom InputStream as
 * the source of the data.  Since the custom InputStream only will
 * return 1 byte at a time this will test the looping behavior in
 * the fill method.  The fill is indirectly called by testBIS1 and
 * testBIS2.  These tests do not exercise the read1 methods loop.  But
 * upon observation, starting Java instance appears to exercise this
 * loop.  Since this occurs, does successful startup qualify as a test
 * for that piece of code?
 *
 * Files affect: java.io.BufferedInputStream
 * BufferedInputStream enhanced with java 6 version:
 * jdk-6-rc-bin-b64-linux-i586-15_dec_2005.bin
 *
 * test ran succesfully on a SUSE 7.3 Linux distribution
 *
 * Brian Harry
 * ###@###.###
 * Jan 15, 2006
 */
public class TestBIS extends TestCase{

    public TestBIS(String method){
	super(method);
    }


    public static class INS2 extends InputStream{
	byte[] data = {0,1,2,3,4,5};
	int current = 0;

	private void waitForever(){
	    try{
		Object lock = new Object();
		synchronized(lock){
		    lock.wait();
		}
	    }
	    catch(InterruptedException ex){}
	}


	public int read(){
	    if(data.length - current > 0){
		return data[current++];
	    }
	    else{
		waitForever();
		return -1;
	    }
	}

	public int available(){
	    if((data.length - current) != 0 ) return 1;
	    return -1;
	}

    }


    public void testBIS1(){
	//this exercises the read functionality...
	out.println();
	out.println("Exercising the read() method...");
	InputStream x = new BufferedInputStream(new INS2(),3);
	try{
	    for(int i = 0; i < 6;i++){
		int b = x.read();
		assertEquals(b,i);
		out.println("reading byte:" + b );
	    }
	}
	catch(IOException io){}
    }

    public void testBIS2(){
	//this exercise the read(byte[], int, int) functionality....
	out.println();
	out.println("Exercising the read(byte[],int,int) method");
	InputStream x = new BufferedInputStream(new INS2(),3);
	try{
	    byte[] b = new byte[100];
	    out.println( "reading 100 bytes");
	    int amount = x.read(b,0,100);
	    assertEquals(amount, 6);
	    out.println( "Amount read was " + amount);
	    for(int i = 0; i < 6; i ++){
		int b2 = b[i];
		assertEquals(b2, i);
		out.println("byte " + i + " is ok");
	    }

	}
	catch(IOException io){}

    }

    public static void main(String ... args) throws IOException{
	
	TestCase tc1 = new TestBIS("testBIS1");
	TestRunner.run(tc1);
	TestCase tc2 = new TestBIS("testBIS2");
	TestRunner.run(tc2);

    }



}


FIX FOR BUG NUMBER:
6192696, 4479751