Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 67161 invoked from network); 7 Aug 2006 11:06:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 7 Aug 2006 11:06:52 -0000 Received: (qmail 75151 invoked by uid 500); 7 Aug 2006 11:06:49 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 74967 invoked by uid 500); 7 Aug 2006 11:06:48 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 74956 invoked by uid 99); 7 Aug 2006 11:06:48 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Aug 2006 04:06:48 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of ilya.okomin@gmail.com designates 66.249.92.173 as permitted sender) Received: from [66.249.92.173] (HELO ug-out-1314.google.com) (66.249.92.173) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Aug 2006 04:06:47 -0700 Received: by ug-out-1314.google.com with SMTP id u40so11399ugc for ; Mon, 07 Aug 2006 04:06:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Y/pYo9nOsmnG9zTxu2u26EOKh3ulhZrH8CuklrznNW6sp25xwLiByFavpUIcDL5qreLpGIA6DmMSmczmrYXC4r3s/7FpzKdr9Bl30TvVNlct0VIoUoZO4GLlfT6E2AqtjiPJ6pbAd4wmTf0CbkgtxCFUuD7eXRgASYZba56j91M= Received: by 10.67.100.17 with SMTP id c17mr7841195ugm; Mon, 07 Aug 2006 04:06:25 -0700 (PDT) Received: by 10.66.250.11 with HTTP; Mon, 7 Aug 2006 04:06:25 -0700 (PDT) Message-ID: Date: Mon, 7 Aug 2006 15:06:25 +0400 From: "Ilya Okomin" To: harmony-dev@incubator.apache.org Subject: Re: [classlib][luni] Strange serialized form of java.util.TreeMap (re JIRA harmony-1066) In-Reply-To: <44D6E161.7070004@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_75335_28727135.1154948785790" References: <44D6E161.7070004@gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_75335_28727135.1154948785790 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 8/7/06, Spark Shen wrote: > Hi: > This is a long post, thanks for your patient to read it through :-) > > I wrote a test case as below: > public void test_SubMap_Serializable() throws Exception { > TreeMap map = new TreeMap(); > map.put(1, 2.1); > map.put(2, 3.1); > map.put(3, 4.5); > map.put(7, 21.3); > SortedMap headMap = map.headMap(3); > assertTrue(headMap instanceof Serializable); > assertFalse(headMap instanceof TreeMap); > assertTrue(headMap instanceof SortedMap); > } > Which says the returned headMap is not a TreeMap but a serializable > SortedMap. > > IIRC, there are three mysterious serialized form immediately following > the serialized form of java.util.TreeMap. They are > > Class **java.util.TreeMap$1** extends Object implements Serializable > > Class **java.util.TreeMap$2** extends Object implements Serializable > > Class **java.util.TreeMap$3** extends Object implements Serializable > > respectively. This gives a hint that there are three inner classes of > TreeMap which should be serializable. > But what are they indeed? > IMHO, the returned SortedMap may > be one of the java.util.TreeMap$x classes. What is your opinion? (I > raised JIRA-1066 for this) > > The above test case suggests me to make the returned SortedMap > serializable. But, I have another concern: > SortedMap returned by TreeMap is not a public class(does not have a > documented Serialized form), and the serialization behavior of this > SortedMap is strange. See the test case below: > public void test_HeadMap_Serializable() throws Exception { > TreeMap map = new TreeMap(); > map.put(1, 2.1); > map.put(2, 3.1); > map.put(3, 4.5); > map.put(7, 21.3); > SortedMap headMap = map.headMap(3); > assertTrue(headMap instanceof Serializable); > assertFalse(headMap instanceof TreeMap); > assertTrue(headMap instanceof SortedMap); > > // Write the SortedMap out and read it back. > ByteArrayOutputStream bos = new ByteArrayOutputStream(); > ObjectOutputStream oos = new ObjectOutputStream(bos); > oos.writeObject(headMap); > oos.close(); > > ByteArrayInputStream bis = new > ByteArrayInputStream(bos.toByteArray()); > ObjectInputStream ois = new ObjectInputStream(bis); > Object outputObject = (Object) ois.readObject(); > > *assertNull(((SortedMap)outputObject).entrySet()); > > assertNotNull(((SortedMap)outputObject).keySet()); > > assertNotNull(((SortedMap)outputObject).values()); > > * *// assertEquals(outputObject, headMap);* > } > > The commented out assertion will throw out a NullPointerException, and > the entrySet of the SortedMap is Null while keySet and values are not. > This is strange. Do we need to follow RI to make the returned SortedMap > serializable like this? Following the spec, Map object equals to given object if they are both implements Map and they are represents the same mapping. If the outputObject has null entry set I suppose NPE on RI could be a result of unhandled access to a null entry set object. As for private SortedMap implementation for TreeMap.headMap() serialization issue, IMHO on Harmony it works correctly and we shouldn't follow RI behaviour. I don't see any reasons to return null as a result of entrySet() call instead of set view of the mappings after deserialization. > Best regards > > -- > Spark Shen > China Software Development Lab, IBM > > > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org > For additional commands, e-mail: harmony-dev-help@incubator.apache.org > > -- -- Ilya Okomin Intel Middleware Products Division ------=_Part_75335_28727135.1154948785790--