FULL PRODUCT VERSION :
java version "1.6.0_11"
Java(TM) SE Runtime Environment (buld 1.6.0_11-b03)
Java Hotspot(TM) Server VM (build 11.0-b16 mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Sparc Solaris 10

A DESCRIPTION OF THE PROBLEM :
Using a FileInputStream to read and process the bytes of a file, after a while it appears that the inputstream and buffer to hold what was read are out of sync.  The problem finally becomes apparent when trying to convert a String to an int.  However, because the buffer is at a different location than expected, a NumberFormatException is thrown (the data is not not an String version of an int).

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
The issue was introduced with build 10 of version 1.6.  The previous build 7 of version 1.6 works correctly.

I do have a sample application that demonstrates the issue.  It consistently demonstrates the issue.  However, the issue seems to be related to a large input stream.  Therefore, my sample application provides a large data file (4MB).


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Although the data is in a very domain-specific format, the issues is presented when a series of bytes are read as a String and then the String is converted to an int.  The expected result would be an int that was represented by the String.
ACTUAL -
With version 1.6.0_07, the byte array is correctly converted to String to int.
With version 1.6.0_10 or 1.6.0_11, the byte array is pointing to incorrect data.

The issue is frequently consistent in the place in which the issue is manifest.  However, it is not always.  In fact, debugging the application will affect where the issue is manifest -- if at all.  If I slow down the processing or reading of the inputstream, the problem is rarely occurs.  But it always occurs when running the application.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Here is the stack trace:

java.lang.NumberFormatException: For input string: "...."
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:447)
at java.lang.Integer.parseInt(Integer.java:497)
...

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
As mentioned before, I do have a sample application (400 lines) that demonstrates the issue.  The problem is that is it dependent on an external data file (4MB).  Is there a way that I can send both the java source file and the data file?
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
The only workaround is to use a build 7 or version 1.6.  Build 10 and 11 both demonstrate the issue.

Release Regression From : 6u7
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.