Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of oleg.v.khaschansky@gmail.com
 designates 64.233.182.184 as permitted sender)
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:content-transfer-encoding:content-disposition:references;
        b=KuEe2u3H88i6wMzzeNWJlrjYu0zfssDLnXfNXExe9Ai4vbhxlbYJ0DEygqC1GRmqZGHn7Z004Bf0Fsj1J8Ybt6KRj0lU/SM9043XMVd6CkU0gK9g72akZ56wUfAAi1PTiMcG35hNCBr5miyeMO5i4n9jYRyENFVLxWqZyE6RsJk=
Message-ID: <26c14c2a0608070452t7a9645c2xc3c7832ee5aaa35@mail.gmail.com>
Date: Mon, 7 Aug 2006 15:53:00 +0400
From: "Oleg Khaschansky" <oleg.v.khaschansky@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] Strange serialized form of java.util.TreeMap (re
 JIRA harmony-1066)
In-Reply-To: <c79906b30608070418x74924a2cycb9248992d0ce611@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <44D6E161.7070004@gmail.com>
	 <26c14c2a0608070316x6630555bnb397f92ced27b770@mail.gmail.com>
	 <c79906b30608070418x74924a2cycb9248992d0ce611@mail.gmail.com>

Follow the link and take a close look at the classes after TreeMap's
form. There are serialization forms for the inner classes mentioned
above, am I correct?

On 8/7/06, Ilya Okomin <ilya.okomin@gmail.com> wrote:
> On 8/7/06, Oleg Khaschansky <oleg.v.khaschansky@gmail.com> wrote:
> >
> > Hi,
> >
> > Take a look at this:
> > http://download.java.net/jdk6/docs/api/serialized-form.html
> > Maybe this document will give you an idea of what are those inner
> > classes... Of cause, in the new release serialized form may have
> > changed.
>
>
> Oleg, ASFAIK the main issue is that TreeMap.headMap() returns the private
> implemention of SortedMap class. This SortedMap implementation serializable
> on RI, but it is undocumented in the spec. Spark Shen has just provided
> tests that show strange behavior of serialization and deserialization of
> this SortedMap implementation on RI.
> I'm not sure we can find anything usefull on the link you've provided,
> because there only serialization forms for public classes are described (if
> I'm not mistaken:)).
>
> Thanks,
> Ilya.
>
> --
> > Oleg
> >
> > On 8/7/06, Spark Shen <smallsmallorgan@gmail.com> 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<Integer, Double> map = new TreeMap<Integer, Double>();
> > >        map.put(1, 2.1);
> > >        map.put(2, 3.1);
> > >        map.put(3, 4.5);
> > >        map.put(7, 21.3);
> > >        SortedMap<Integer, Double> 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<Integer, Double> map = new TreeMap<Integer, Double>();
> > >        map.put(1, 2.1);
> > >        map.put(2, 3.1);
> > >        map.put(3, 4.5);
> > >        map.put(7, 21.3);
> > >        SortedMap<Integer, Double> 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?
> > >
> > > 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
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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
>
>

---------------------------------------------------------------------
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