Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 41694 invoked from network); 18 Dec 2006 13:07:40 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 18 Dec 2006 13:07:40 -0000 Received: (qmail 61829 invoked by uid 500); 18 Dec 2006 13:07:43 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 61794 invoked by uid 500); 18 Dec 2006 13:07:42 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 61764 invoked by uid 99); 18 Dec 2006 13:07:42 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Dec 2006 05:07:42 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of zhanghuangzhu@gmail.com designates 64.233.182.187 as permitted sender) Received: from [64.233.182.187] (HELO nf-out-0910.google.com) (64.233.182.187) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Dec 2006 05:07:32 -0800 Received: by nf-out-0910.google.com with SMTP id a4so1968733nfc for ; Mon, 18 Dec 2006 05:07:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=d+ARdGUr66jwczOgVMEcKCUlLHRm2NT1xQolf8BCgZp+hebv1xkc18zm2xAYR5nG/EVcTiK1/24NO3h454N0yoLnxXRFgOeJBJISYLJIrlXiBkh1VoQVrLCMmQqgLnAULNGa/TkSnPa2kS+/FZ1wGZqm7uQhi7SiRRUzTdj1ulM= Received: by 10.82.127.15 with SMTP id z15mr540793buc.1166447230911; Mon, 18 Dec 2006 05:07:10 -0800 (PST) Received: by 10.82.115.8 with HTTP; Mon, 18 Dec 2006 05:07:10 -0800 (PST) Message-ID: <4d0b24970612180507l2335fd93nada6d1b61b39b9ee@mail.gmail.com> Date: Mon, 18 Dec 2006 21:07:10 +0800 From: "Andrew Zhang" To: dev@harmony.apache.org Subject: [classlib][sql] SerialBlob.setBytes exception thrown compatibility issue MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_14466_27046781.1166447230809" X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_14466_27046781.1166447230809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi guys, It's SerialBlob again. It's the third time to ask similar question about SerialBlob class. :) Let's take a look at the spec of setBytes(long pos,byte [] bytes, int offset, int length). Throws SerialException - if there is an error accessing the BLOB value; if an invalid position is set; if an invalid offset value is set; if number of bytes to be written is greater than the SerialBlob length; or the combined values of the length and offset is greater than the Blob buffer As my understanding, the tortuous words shows that setBytes should throw SerialException if there's any array index outbound. But following code shows that RI's behaviour looks weird: public void testSetBytes() throws Exception { byte[] buf = { 1, 2, 3, 4, 5, 6, 7, 8 }; byte[] theBytes = { 9, 9, 9 }; SerialBlob serialBlob = new SerialBlob(buf); serialBlob.setBytes(7, theBytes); // ArrayIndexOutOfBoundsException serialBlob.setBytes(7, theBytes, 0, 3); // ArrayIndexOutOfBoundsException serialBlob.setBytes(7, theBytes, 0, 10); // SerialException } Let's look at the spec again, what does "the combined values of the length and offset is greater than the Blob buffer " mean? The previous sentence already says "if number of bytes to be written (length) is greater than the SerialBlob length(Blob buffer)". The spec of another similar method setBytes(long pos, byte[] bytes) looks more interesting: SerialException - if there is an error accessing the BLOB value; or if an invalid position is set; if an invalid offset value is set But who can tell me what does "if an invalid offset value is set" mean? :-) The SerialBlob class looks scary to me. What shall we do for setBytes? Follow RI or always throw SerialException for invalid array index? Personally I prefer to the latter one, and if it breaks any existing application or fails TCK tests later, then let's fix it. Any suggestions/comments? Thanks in advance! -- Best regards, Andrew Zhang ------=_Part_14466_27046781.1166447230809--