Closed caglartolgatetik closed 6 years ago
can you provide a testcase+jdk+fst version ?. I had similar issues because of the weird constructor mechanics of java's collection (deserializer cannot call default constructor in some cases). Did you subclass HashMap ?
Java: java version "1.8.0_73" Java(TM) SE Runtime Environment (build 1.8.0_73-b02) Java HotSpot(TM) 64-Bit Server VM (build 25.73-b02, mixed mode) Fst Version: 2.52
We are still trying to reproduce the issue. We have not subclassed the HashMap. Please see my comments below in FstMapSerializer class.
@Override
public Object instantiate(Class objectClass, FSTObjectInput in, FSTClazzInfo serializationInfo, FSTClazzInfo.FSTFieldInfo referencee, int streamPosition) throws Exception {
Object res = null;
int len = in.readInt(); // readInt returns -1 in our case
if ( objectClass == HashMap.class ) { //when objectClass is HashMap I guess it never calls the default constructor
res = new HashMap(len);
} else
if ( objectClass == Hashtable.class ) {
res = new Hashtable(len);
} else
{
res = objectClass.newInstance();
}
in.registerObject(res, streamPosition,serializationInfo, referencee);
Map col = (Map)res;
for ( int i = 0; i < len; i++ ) {
Object key = in.readObjectInternal(null);
Object val = in.readObjectInternal(null);
col.put(key,val);
}
return res;
}
This seems to be our mistake. Since HashMap is not threadsafe it's possible to get HashMap size as -1 if you try removing items concurrently.
My idea is; if HashMap size is -1, it also means that the map is empty. Would it make sense to assume the map initial size as 0 while deserializing ( or serializing ) in this case?
yeah there could be a catch on this, however this would just hide a multithreading error :)
I serialized an object including a hashmap field using FSTMapSerializer class, but while deserializing it, I got the following exception. We know that hashmap size cannot be negative number, but somehow while reading or writing it became -1.