On 8/7/06, Spark Shen <[EMAIL PROTECTED]> 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?
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
--
Ilya Okomin
Intel Middleware Products Division
