JDK-6428395 : Potential problem with handling read() javax.sql.rowset.serial.SerialClob.position(...)
  • Type: Bug
  • Component: core-libs
  • Sub-Component: javax.sql
  • Affected Version: 6
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2006-05-20
  • Updated: 2014-02-27
  • Resolved: 2007-07-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
6u4 b01Fixed
Current implementation of
javax.sql.rowset.serial.SerialClob.position(Clob searchStr, long start)
has following code:

   311      public long position(Clob searchStr, long start)
   312          throws SerialException, SQLException {
   314          char cPattern[] = null;
   315          try {
   316              java.io.Reader r = searchStr.getCharacterStream();
   317              cPattern = new char[(int)searchStr.length()];
   318              r.read(cPattern);
   319          } catch (IOException e) {
   320              throw new SerialException("Error streaming Clob search data");
   321          }
   322          return position(new String(cPattern), start);
   323      }

However, Reader.read(byte[] b) doesn't guarantee that exactly b.length
bytes will be read. So, the code has potential problems in case less than b.length
bytes are returned. While this is probably hardly reproducible in real
apps theoretically it might happen - so it seems better to update code to protect from this.

    int totalRead = 0;
    while ( totalRead < cPattern.length() )
        totalRead += r.read(cPattern, totalRead, cPattern.length - totalRead);

Btw, why just don't use searchStr.getSubString(0, searchStr.length)
instead of reading from the streams?
Looks like from performance point of view it is better to use getSubString.

EVALUATION Deferring it to next release of jdk