Excluding fields without annotation leads to empty object

[muntzen]

I'm not sure there is anything "wrong" with this, but is there a way
to tell the Gson class to not write empty objects? For example, I am
using the excludeFieldsWithoutExposeAnnotation() method on GsonBuilder
to create a Gson instance that only writes fields with the expose
annotation. However, when I do this, and the fields I want exposed
are null, I get empty objects in the JSON output. Here is an example
unit test...

import com.google.gson.Gson;
import com.google.gson.GsonBuilder;
import com.google.gson.annotations.Expose;
import static junit.framework.Assert.assertEquals;
import org.junit.Test;

public class GsonAnnotationTest
{
@Expose String val;

public GsonAnnotationTest() {}

public GsonAnnotationTest(String val) {
this.val = val;
}

@Test
public void noValsTest()
{
GsonBuilder builder = new GsonBuilder();
Gson gson = builder.excludeFieldsWithoutExposeAnnotation().create();

GsonAnnotationTest[] testArray = {
new GsonAnnotationTest("test1"),
new GsonAnnotationTest(null),
new GsonAnnotationTest("test3")
};

assertEquals(gson.toJson(testArray), "[{\"val\":\"test1\"},{\"val\",
\"test3\"}]");
}
}

The output from the test is actually:
[{"val":"test1"},{},{"val":"test3"}]

And that's probably not incorrect, but I'd like a way to not write
empty objects. Is there an existing setting that provides this
functionality?

Thanks
-Eric

[Inderjeet Singh]

You raise a good point. If an object is empty, then we should not write it (keeping with our philosophy of writing minimal possible JSON).
Can you file a bug on this in our Issue Tracker?

Thanks for the detailed example illustrating your point.
Inder

[Inderjeet Singh]

I thought more about it, and now I am not sure if supporting this is a good idea.

An empty object is not the same as a null object. An empty object is not null, but all of its fields are null.
So, eliminating it from output JSON loses information.

Any comments?
Inder

[Eric Muntz]

Hmm, good point. I agree there are some times when knowing it was not
null is helpful, if it's in JSON in a situation where the object to be
written is an attribute of another object:

{ "var1" : {}, "var2" : { "var2.1" : "foobar", ...}, ...}

In that case, it's nice to know that var1 wasn't null, when building
the resulting object out of that, you could instantiate an empty
object.

My issue centered around the insertion of an empty object in an array,
which probably isn't a terrible situation either - at least you know
the size of the array being (de)serialized. Now that we're discussing
it, I'm not sure a change is a good idea either, as you said, it
creates some loss, and does seem worse than instantiating an empty
object. After this discussion, I guess the most I would ask for now
is a setting to not write empty objects, so at least we can control it
if we find it helps in some ways (in my current implementation, the
loss won't be harmful).

And, of course, I already added the bug before your response. :)
http://code.google.com/p/google-gson/issues/detail?id=30

-Eric

[Inderjeet Singh]

Hi Eric,

For the case of an array, actually writing out the nulls, or empty objects is crucial since an array is an ordered collection, and the index of each element matters.

So, are you proposing that this setting will eliminate the empty (and null as well) entries from the array, thereby changing the indices of other elements?

For Objects with null or empty fields, it is somewhat meaningful where you are essentially asking to treat empty objects as null objects. I am still concerned about the semantic implications of that setting. It doesnt feel right to me.

May be you can give some specific cases where treating empty objects as null will be useful.
Thanks
Inder

[Eric Muntz]

On Thu, Aug 7, 2008 at 1:21 AM, Inderjeet Singh <inde...@gmail.com> wrote:
> For the case of an array, actually writing out the nulls, or empty objects
> is crucial since an array is an ordered collection, and the index of each
> element matters.

I disagree that the index of each element matters in all cases. If
you simply have a collection and all that matters is you had a
collection, then the index of each element doesn't matter. If what
you are trying to accomplish is to build an exact identical
representation of an object in JSON notation, then it does matter.
However, that is not the only valid use case. If you are using JSON
notation as simply a way to transmit information and your API only
cares about representing a collection of objects, it seems valid to me
to not send empty objects. It seems that the
excludeFieldsWithoutExposeAnnotation indicates the desire to not
always serialize exact representations of objects, and only provide
the elements for a specific situation... if none of those elements are
non-null in the object, why would your system care about serializing
them?

In my case, I am serializing a collection of objects and it turns out
some of them have null values for the attributes my API cares about,
in which case, I'd rather not even send them to my clients via JSON.
Seems like a valid use case to me, and if I'm sending empty objects,
my client will need to know to do nothing with that object.

In the end, it's not really a huge deal, I have alternatives - I could
make a pass through the collection and remove the objects that aren't
pertinent. I could write an implementation of JsonSerializer for the
collection that weeds out the non-pertient objects and then I'm not
even iterating through the collection twice. It just seemed like a
useful setting to build into the library, though I understand your
hesitation.

-Eric

[Inderjeet Singh]

I see. You are right that the order matters only for Lists, not collections.
However, having a general setting will exclude null elements from ALL collections including lists.
What you probably want is to control behavior of a specific type. As you point out, that is better
done through a JsonSerializer where you return a JsonNull if the object is going to be empty.

Based on the discussions, it seems that you are comfortable with the alternate solutions, so I will close this bug for now.
Thanks
Inder

-Erice-gson?hl=en

-~----------~----~----~----~------~----~------~--~---