Empty list turns into null after serialization/deserialization

[GoogleCodeExporter]

What steps will reproduce the problem?
public class Foo implements Externalizable {

    private List<String> list;
...
}

        Foo foo = new Foo();
        foo.setList(new ArrayList<String>());

What is the expected output? What do you see instead?
Empty list becomes null after the roundtrip

Before Externalized = Foo [list=[]]
NewFoo = Foo [list=null]

What version of the product are you using? On what operating system?
1.0.0.M3

Please provide any additional information below.

Original issue reported on code.google.com by songyang...@gmail.com on 14 Sep 2010 at 5:39

[GoogleCodeExporter]

This is by design.
If you have an empty list, nothing gets serialized from that list.
The concept is about "merging" data on deserialization.
Therefore your list won't be touched because there is nothing to merge from the 
serialized bytes.

I suggest you declare your list as:
private List<String> list = new ArrayList<String>();

Its a common javabean convention.

Original comment by david.yu...@gmail.com on 15 Sep 2010 at 6:38

• Changed state: WontFix

[GoogleCodeExporter]

The other solution to this is make the RuntimeSchema.writeTo obtrusive.
E.g when it sees an empty list, it sets it to null.
I'm not entirely sure if this is the way to go.

Original comment by david.yu...@gmail.com on 15 Sep 2010 at 6:44

[GoogleCodeExporter]

I disagree.  A list itself is a java object, regardless of it's empty or not.  
It would impose too many restrictions on class definitions if empty collections 
or any other container class to be instantiated at declaration time.

For example, if you comment out this line in issue 30, the test would fail.
//      foo.getList().add("New String");

Original comment by songyang...@gmail.com on 15 Sep 2010 at 5:33

[GoogleCodeExporter]

A list simply holds the values of the repeated fields.  The values are the ones 
being serialized and deserialized.

From a java standpoint you are correct.  Since java's built-in serialization 
also serializes the list that holds the values. It serializes all the objects 
while protostuff serializes all the values.  That is by design (think protobuf)

Original comment by david.yu...@gmail.com on 16 Sep 2010 at 3:53

[GoogleCodeExporter]

If by design, the design is flawed.  User has control over protobuf on what 
goes in and what comes out, whereas in protostuff case, one can only hope the 
same object comes out as the on goes in.  Anything less renders it less useful 
for general purpose serialization/deserialization.  Also, I found it's a 
nuisance that protostuff requires each class to declare a zero argument 
constructor, instead of searching for any available constructor.

Original comment by songyang...@gmail.com on 16 Sep 2010 at 4:22

[GoogleCodeExporter]

Fixed.  Simply set the property 
-Dprotostuff.runtime.collection_schema_on_repeated_fields ... w/c serializes 
the collection itself (even if its empty).

Original comment by david.yu...@gmail.com on 8 Feb 2011 at 7:54

• Changed state: Fixed