Problem with a large String and StringBuffer objects - indexOf methods

Hi All,

This maybe a bug. Please read on.

I have come across some odd behaviour with the java.lang.String and java.lang.StringBuffer classes indexOf methods. In particular thepublicint indexOf(String str,int fromIndex)

Both class have this method for details visit

for java.lang.String read

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/String.html#indexOf(java.lang.String,%20int)

and for java.lang.StringBuffer read

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/StringBuffer.html#indexOf(java.lang.String,%20int)

I'll assume that you've read the above to links. Now I have created a String object from an array of characters read from a file by a java.io.BufferedReader object that was constructed with a java.io.FileReader object. The contents of the file (a HTML document) are dumped into the String ( this approximately 200,000 bytes of data). When I call the above method the indexOf(str, fromIndex)

the methods exhibit a cyclic search behaviour i.e. if asked to search for the substring, str, from index 100,000 the method searches from 100,000 to the end of the buffer. If str was NOT found it then commences to search from the start of the buffer only returning -1 if str is NOT in the first portion of the buffer otherwise returning the index of str in the first protion of the buffer (NOT the desired or EXPECTED behaviour). This behaviour however does NOT occur for small buffers. i.e. I can only get the error to occur with the large buffers, 200,000+ characters.

I have thoroughly tested using a 'fromIndex' such that I know the desired substring is in the lower portion of the buffer and not in the upper portion. However the method simply searchs the upper portion and then jumps to the start of the buffer and searchs the lower portion and returns the index of the substring in the first portion. (NOT excepted behaviour).

I also found this unexpected behaviour also occurs with StringBuffer objects.

Has anyone found similar ?

Did I miss something in the documentation?

Unfortunately I can't post my code but I will write some test code (and post it) to see if I can replicate the bug - so far I have shown that the code works as expected for small buffers (I'm not sure at what size the behaviour becomes unpredictable so small is less than 200).

Hopfully someone can shed some light

Thanks

Michael

[2586 byte] By [mjwok2004] at [2007-9-30 14:38:25]
# 1

Works for me with this test harnesspublic class Test {

public static void main(String[] args)

{

int size = 0;

try {

size = Integer.parseInt(args[0]);

}

catch (Exception e) {

e.printStackTrace();

}

StringBuffer sb = new StringBuffer();

for ( int i=0; i<size; i++ ) {

sb.append('a');

}

// Change the last two a's to b's

sb.setCharAt(sb.length()-1, 'b');

sb.setCharAt(sb.length()-2, 'b');

// Make sure this is right

if ( sb.length() >< 15 ) System.out.println( sb.toString() );

System.out.println( "bb at position " + sb.indexOf("bb", size/2) );

}

}

EvilEdna at 2007-7-5 14:14:01 > top of Java-index,Administration Tools,Sun Connection...
# 2

Embarassed but replying.

The bug has been found in a 3rd party module.(I din't think I would find a bug in java.lang class) I rewrote the classes that used the StringBuffer class and the error occured only after the inclusion of a native class used for processing a chunk of the data - still haven't figured out how it affects the buffer but will do so when I get a chance and post the result. FYI the native module as far as I know the class binds Fortran to C and then C to JNI. (I've probably mis-interpretted the interface specification for the module, I'm pretty sure its modifiying a variable that it think it shouldn't be - which is affect my "pointer" into the buffer).

Oh yeah and my test harness returned the expected result like yours (for wide range of inputs).

mjwok2004 at 2007-7-5 14:14:01 > top of Java-index,Administration Tools,Sun Connection...