I understand what you and Andreas are saying, but even if i look at
copyValueOf, the docs are not clear at the expected behavior.
Unfortunately, what ends up happening is for items that are not
explicit, then they often take a life of their own and imitation is the
biggest form of flattery.
The JDBC methods should, as much as the possibly can, be consistent with
the behavior of methods in the JDK. This specific issue could easily be
argued either way and I see it from a different point of view and
perhaps it is also all my years of FTN/C programming as well.
At the end of the day, it really does not matter what my own opinion is,
it is coming to a consensus within the JDBC EG on the correct behavior.
Unfortunately, there are cases where i have had to document the behavior
as implementation defined given it can be too late to have the vendors
all come to the same agreement and be willing to change their
implementations. This issue is more of an overall corner case, so i am
not going to lose to much sleep over it regardless of how it turns out
in the EG.
Regards
Lance
Actually that example is quite misleading because the second parameter
does not specify a number of characters but rather a second index,
which obviously can only be 0 if the first index is 0 (which btw.
works without problems and returns an empty string). This is different
from Clob.getSubString where the second parameter is the number of
characters.
A probably more fitting example would be something like:
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html#copyValueOf(char[],%20int,%20int)
E.g. a program like this:
public class Main
{
public static void main(String[] args)
{
char[] test = { 'S', 'o', 'm', 'e', ' ', 'T', 'e', 's',
't', '
', 'S', 't', 'r', 'i', 'n', 'g' };
String testStr1 = String.copyValueOf(test, 5, 4);
String testStr2 = String.copyValueOf(test, 5, 0);
System.out.println("Test strings: #1=" + testStr1 + ", #2=" +
testStr2);
}
}
works without problems, even if the number of characters to copy is 0.
Coming back to the Clob.getSubString() method, from my experience,
Derby is the only database that does not allow 0 as the number of
characters to return. The JDBC drivers of all other databases that I
have tried - Oracle, DB2, Sql Server, MySql, PostgreSql, and some
others - simply return empty strings. This is why I implemented the
part of DdlUtils that way, because the API did not say anything about
0 being a value that is not allowed to use (and as Craig pointed out,
it makes sense to allow it for consistency).
cheers,
Tom
