NullPointerException when using FSTObjectInputNoShared
The following code produces a NullPointerException in unshared mode:
List<URI> list = new ArrayList<>();
list.add(URI.create("about:blank"));
FSTConfiguration config = FSTConfiguration.createDefaultConfiguration();
config.setShareReferences(false);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
FSTObjectOutput output = new FSTObjectOutputNoShared(baos, config);
output.writeObject(list);
output.close();
byte[] bytes = baos.toByteArray();
ByteArrayInputStream bais = new ByteArrayInputStream(bytes);
FSTObjectInput input = new FSTObjectInputNoShared(bais, config);
input.readObject();
input.close();
The stack trace is the following:
Exception in thread "main" java.io.IOException: java.lang.NullPointerException
at org.nustaq.serialization.FSTObjectInput.readObject(FSTObjectInput.java:243)
Caused by: java.lang.NullPointerException
at org.nustaq.serialization.FSTObjectInput.readObjectWithHeader(FSTObjectInput.java:353)
at org.nustaq.serialization.FSTObjectInput.readObjectFields(FSTObjectInput.java:708)
at org.nustaq.serialization.FSTObjectInputNoShared.instantiateAndReadNoSer(FSTObjectInputNoShared.java:94)
at org.nustaq.serialization.FSTObjectInput.readObjectWithHeader(FSTObjectInput.java:370)
at org.nustaq.serialization.FSTObjectInput.readObjectInternal(FSTObjectInput.java:327)
at org.nustaq.serialization.serializers.FSTArrayListSerializer.instantiate(FSTArrayListSerializer.java:63)
at org.nustaq.serialization.FSTObjectInput.instantiateAndReadWithSer(FSTObjectInput.java:497)
at org.nustaq.serialization.FSTObjectInput.readObjectWithHeader(FSTObjectInput.java:366)
at org.nustaq.serialization.FSTObjectInput.readObjectInternal(FSTObjectInput.java:327)
at org.nustaq.serialization.FSTObjectInput.readObject(FSTObjectInput.java:307)
at org.nustaq.serialization.FSTObjectInput.readObject(FSTObjectInput.java:241)
The issue has been around since fast-serialization 2.12, the code above works with 2.10 without the NullPointerException. The current version is 2.48.
I am seeing the same problem with using an URI (w/o collection). A testcase is provided in https://github.com/RuedigerMoeller/fast-serialization/pull/168. I didn't find any obvious yet in the code but I will keep on looking. It fails with shared and unshared references.
I think the problem is that on deserializing the default "readObject" method isn' being called (as opposed to the "writeObject"). Thus in the URI class the required fields aren't being set (see the test case which has an internal class similar to what URI/URL are doing)
why not use default output stream ? the performance difference is kind of neglectable, in many cases its even faster ?
@RuedigerMoeller, I am in fact using the default config.getObjectOutput() stream now, the code in this bug report was only the result of some experimenting: I was playing around with replacing config.getObjectOutput() + output.getCopyOfWrittenBuffer() with something that doesn't create thread-local buffers, plus avoids creating both input and output streams on the same side like DefaultCoder does. But this is only a side note; this bug report was created to let you know that if you use FSTObjectInputNoShared in this specific way, you may get a NullPointerException.
thankx :) unshared mode is kind of untested currently (it worked sometime ago ..)