It seems like the serializer is unable to serialize Doubles (ie. the object, not the primitive) if it’s set to null. This seems unintended. Am I right? Was that corner case just overlooked? It seems like it would be fairly trivial to make sure the serializer is able to handle that situation.
Many of the JME serializers incorrectly handle nulls (Vector3f is another painful one). Unfortunately, given the limitations of how serializers were implemented, handling nulls would require breaking the protocol by adding an additional null-check byte to every serializer that is missing this functionality. Many of the primitive wrapper serializers were written with regular primitives in mind (since reflection treats primitives as wrapped primitives) and so don’t think of the null check.
Since it comes up rarely (most people don’t bother to send nulls), fixing it has been put off. I’d really like to convert the whole mess over to bitstreams and build a base protocol version right into the Serializer layer itself so that misversioned clients/servers could fail nicely instead of blowing up randomly. Bitstreams would also let us divorce ourselves of the whole fixed-size ByteBuffer mess we have now… and the null check also becomes only one bit instead of 8.
As a work-around, you can add your own null check by hacking in a second boolean field into your message that tells your reading end that the value is meant to be null… then convert your Double field to a double. You can fix it on your message’s getter for that value.
I don’t know the code that well, but it seems to be that it would be relatively simple to alter the code to check each object it was about to send to see if it was null. If so, it would just send a faux class code, representing null, followed by the code of the class that is null. Then the serialization system would just have to check for this case. Each null could be sent in two bytes (or however large the class code encoder is). Other serializers could then ignore the null case. It would probably save network bandwidth overall.
In my case, though, I’ll just alter my code so it doesn’t depend on a null Double. But this really seems like it’s something that should be part of the code simply for completeness.
You could even catch the null pointer exceptions and only use the NullSerializer in those cases. That way existing serializers that handle nulls wouldn’t be effected.