harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Khaschansky" <oleg.v.khaschan...@gmail.com>
Subject Re: [classlib][luni] Strange serialized form of java.util.TreeMap (re JIRA harmony-1066)
Date Mon, 07 Aug 2006 18:39:04 GMT
> Do you have any ideas where these classes can appear? As far as I
> understand TreeMap#headMap() as well as #subMap() and #tailMap()
> returns instances of TreeMap$SubMap.
Yes.

> IMHO if we cannot get instances
> of these $1 - $3 classes we should not care about it.
But we can get SubMap instance. And its serialization/deserialization
is partly broken in RI. As far as I understood the question is: should
we implement the functionality that is partly broken in RI? But if
there is SubMap already in the TreeMap, why not make a compatible
serialization for it, knowing form? It will be broken in the same way
with RI and work correct with Harmony classlib...

On 8/7/06, Alexei Zakharov <alexei.zakharov@gmail.com> wrote:
> Hi Spark,
>
> > > > IIRC, there are three mysterious serialized form immediately following
> > > > the serialized form of java.util.TreeMap. They are
> > > > Class **java.util.TreeMap$1**
> > > > Class **java.util.TreeMap$2**
> > > > Class **java.util.TreeMap$3**
>
> Do you have any ideas where these classes can appear? As far as I
> understand TreeMap#headMap() as well as #subMap() and #tailMap()
> returns instances of TreeMap$SubMap. IMHO if we cannot get instances
> of these $1 - $3 classes we should not care about it. There are
> several places in the J2SE 5.0 api doc where serialization form for
> non-public classes is described.
>
> Regards,
>
> 2006/8/7, Ilya Okomin <ilya.okomin@gmail.com>:
> > 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
> > > >
> > --
> > Ilya Okomin
> > Intel Middleware Products Division
> >
> >
>
>
> --
> Alexei Zakharov,
> Intel Middleware Product 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
>
>

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


Mime
View raw message