Re: StringBuffer question

[Eric Blake]

Bryce McKinlay wrote:
> 
> However, in the JCL, setLength() and other StringBuffer methods are
> explicitly defined to throw the StringIndexOutOfBoundsException.

Thanks for the clarification.  I will document the methods in question
as:
* @throws IndexOutOfBoundsException <description...>
*        (while unspecified, this is a StringIndexOutOfBoundsException)

Is there a way to access the JCL online?  It's not listed on the Hacking
page: http://www.gnu.org/software/classpath/doc/hacking.html

Another question on the original topic.  Do we try to match which
exception is thrown when multiple problems occur?  For example, new
String(byte[], int, int, String) can throw a NullPointerException from a
null encoding or byte[], IndexOutOfBoundsException from bad indices, or
UnsupportedEncodingException from an unknown encoding. My experiments
show that Sun checks for a null encoding, then for negative indices,
then a null byte[], then indices too large, and finally for an unknown
encoding.  However, Classpath and libjava have different orders for
checking, so the three implementations currently have different behavior
for this snippet:

new String(new byte[1], -1, 0, null);
new String(null, -1, 0, "foobar");

Sun: NullPointer, StringIndexOutOfBounds
Classpath: StringIndexOutOfBounds, StringIndexOutOfBounds
libjava: ArrayIndexOutOfBounds, NullPointer

My opinion is that it doesn't matter which exception is thrown, so long
as one of them is (mainly because checking for a null encoding before
checking bounds, but for an unknown encoding after, is less efficient
then doing both encoding checks at once).  That ArrayIndexOutOfBounds in
libjava should probably be switched to StringIndexOutOfBounds, though.

If it isn't obvious by now, I'm trying to merge String and StringBuffer
between Classpath and libjava, insofar as possible.  This includes
adding better data sharing and substring support to Classpath.  Of
course, I'm tackling the all-Java version of Classpath before trying to
modify gcj with its native support.

-- 
This signature intentionally left boring.

Eric Blake             address@hidden
  BYU student, free software programmer