You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because serialization will work if the object attempting to be serialized is serialized, it does nothing to confirm the underlying objects themselves are serializable. If a field for example is transient but nothing is defined to restore it such as List, then it won't be restored. We should look to enhance this so we can test the contents written are the contents retrieved.
Sample code I used to visually confirm a problem which could be basis for this. This uses mybatis CacheKey as there were questions regarding List and scanners stating not serializable. After testing it was determined that it is serializable if contents themselves are. If the contents is just another bland object, then it is not. However, marking the class transient actually causes a problem resulting in the data being null entirely when reading back the object as it will never be written.
@TestpublicvoidserializationTest() {
CacheKeycacheKey = newCacheKey();
cacheKey.update(newObject());
canSerialize(cacheKey);
}
voidcanSerialize(finalCacheKeyobject) {
ObjectOutputStreamoutput = null;
try {
FileOutputStreamfout = newFileOutputStream("address.ser");
output = newObjectOutputStream(fout);
output.writeObject(object);
} catch (finalIOExceptione) {
Assert.fail(String.format("An exception was thrown while serializing the class '%s': '%s',", object
.getClass().getName(), e.toString()));
} finally {
if (output != null) {
try {
output.close();
} catch (IOExceptione) {
Assert.fail(String.format("An exception was thrown while closing stream for class '%s': '%s',",
object.getClass().getName(), e.toString()));
}
}
}
ObjectInputStreaminput = null;
try {
FileInputStreamfin = newFileInputStream("address.ser");
input = newObjectInputStream(fin);
CacheKeyreadCache = (CacheKey) input.readObject();
intcount = readCache.getUpdateCount();
} catch (Exceptione) {
Assert.fail(String.format("An exception was thrown while serializing the class '%s': '%s',", object
.getClass().getName(), e.toString()));
} finally {
if (input != null) {
try {
input.close();
} catch (IOExceptione) {
Assert.fail(String.format("An exception was thrown while closing stream for class '%s': '%s',",
object.getClass().getName(), e.toString()));
}
}
}
}
The text was updated successfully, but these errors were encountered:
Added code that covers this but testing is very weak at best.
Need to properly name objects a bit better.
Need to have one that has a transient List so that it breaks as that is the use case for deserialization as it will serialize fine but will lose data if populated.
Keeping this open until tests can be further refined and cleaned up. Code is solid and has been adjusted per guidence given over on mybatis.
Because serialization will work if the object attempting to be serialized is serialized, it does nothing to confirm the underlying objects themselves are serializable. If a field for example is transient but nothing is defined to restore it such as List, then it won't be restored. We should look to enhance this so we can test the contents written are the contents retrieved.
Sample code I used to visually confirm a problem which could be basis for this. This uses mybatis CacheKey as there were questions regarding List and scanners stating not serializable. After testing it was determined that it is serializable if contents themselves are. If the contents is just another bland object, then it is not. However, marking the class transient actually causes a problem resulting in the data being null entirely when reading back the object as it will never be written.
The text was updated successfully, but these errors were encountered: