Re: StringBuffer question
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 *(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 [EMAIL PROTECTED] BYU student, free software programmer ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: StringBuffer question
Eric Blake wrote: >So back to my original question: Is the bounds check in the current >Classpath implementation of setLength necessary, or am I justified in >breaking the above snippet by removing the bounds check and throwing >IndexOutOfBoundsException instead? > Iit would be nice to do that, and it would not be incorrect according to the JDK 1.4 docs. However, in the JCL, setLength() and other StringBuffer methods are explicitly defined to throw the StringIndexOutOfBoundsException. Although I'm usually inclined to follow the Javadoc spec in preference to the JCL, given that there is some chance that changing it would break exisiting code, in this case I think it is safer to stick with the existing behaviour. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: StringBuffer question
Brian Jones wrote:
>
> I cannot get at the javadoc at the moment for 1.4, it seems to only
> partially load. The implementation should match what is specified
> explicitly, and where such language is missing match behaviour
> instead. Generally, software written to specification should not fail
> with Classpath if it works in Sun's VM is what I think we strive toward.
You're not the only one having problems reading the javadoc. The web
page ends on a '\0' character - I think their server is truncating the
file when it hits the embedded null. What I ended up doing, however,
was to download the documentation package (30 MB!) from Sun, and that
zip file contains a clean version of the StringBuffer.html file.
For example, setLength, the method that got truncated by Sun's servers,
is documented thus:
"public void setLength(int newLength)
...
"Parameters: newLength - the new length of the buffer.
"Throws: IndexOutOfBoundsException - if the newLength argument is
negative.
"See Also: length()"
Yet my experiments show that Sun's implementation throws
StringIndexOutOfBoundsException. Consider this code snippet:
void m(StringBuffer s, int i)
{
try
{
s.setLength(i);
}
catch (StringIndexOutOfBoundsException e)
{
}
}
If you call m(new StringBuffer(), -1), the exception will be trapped by
Sun's implementation, but that behavior was not strictly documented. So
back to my original question: Is the bounds check in the current
Classpath implementation of setLength necessary, or am I justified in
breaking the above snippet by removing the bounds check and throwing
IndexOutOfBoundsException instead?
public synchronized void setLength(int newLength)
{
// If this bounds check is skipped...
if (newLength < 0)
throw new StringIndexOutOfBoundsException(newLength);
ensureCapacity_unsynchronized(newLength);
for (int i = count; i < newLength; ++i)
// ... this line will throw IndexOutOfBoundsException
value[i] = '\0';
count = newLength;
}
--
This signature intentionally left boring.
Eric Blake [EMAIL PROTECTED]
BYU student, free software programmer
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Removing pthread and gthread
Carlos Cavanna <[EMAIL PROTECTED]> writes: > Hi, > > I need to compile a version of classpath that > does not link with neither -lpthread nor -lgthread > (that is all I need to remove). > > What would be the correct procedure to do it ? > I tried commenting out: >AM_PATH_GLIB(1.2.4,,exit 1,gthread) > > from configure.in but that is not a nice solution > as it seems to remove more than is necessary. > There has to be a higher level solution. Essentially work in a patch to configure.in and Makefile.am that leaves out the relevant checks when leaving out the gtk peers. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: StringBuffer question
Eric Blake <[EMAIL PROTECTED]> writes: > How strictly do we want to match Sun on StringBuffer? In the 1.4 > Javadoc, many of the methods specify only @throws > IndexOutOfBoundsException, which can be done as a side-effect of array > operations. Yet the JDK implementation seems to throw > StringIndexOutOfBoundsException (a subclass), which requires explicit > bounds checking. The current Classpath implementation is a mix of both > approaches, depending on which method you look at. It would be nice if > it were consistent. > > Should we let the VM generate the more general exception implicitly, > skipping explicit checks where possible; or should I make sure that > Classpath throws the more specific StringIndexOutOfBoundsException any > time Sun does? I cannot get at the javadoc at the moment for 1.4, it seems to only partially load. The implementation should match what is specified explicitly, and where such language is missing match behaviour instead. Generally, software written to specification should not fail with Classpath if it works in Sun's VM is what I think we strive toward. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Removing pthread and gthread
Hi, I need to compile a version of classpath that does not link with neither -lpthread nor -lgthread (that is all I need to remove). What would be the correct procedure to do it ? I tried commenting out: AM_PATH_GLIB(1.2.4,,exit 1,gthread) from configure.in but that is not a nice solution as it seems to remove more than is necessary. There has to be a higher level solution. Thanks, CC __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
StringBuffer question
How strictly do we want to match Sun on StringBuffer? In the 1.4 Javadoc, many of the methods specify only @throws IndexOutOfBoundsException, which can be done as a side-effect of array operations. Yet the JDK implementation seems to throw StringIndexOutOfBoundsException (a subclass), which requires explicit bounds checking. The current Classpath implementation is a mix of both approaches, depending on which method you look at. It would be nice if it were consistent. Should we let the VM generate the more general exception implicitly, skipping explicit checks where possible; or should I make sure that Classpath throws the more specific StringIndexOutOfBoundsException any time Sun does? -- This signature intentionally left boring. Eric Blake [EMAIL PROTECTED] BYU student, free software programmer ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
