Custom deserializer not called for explicit null value

[GoogleCodeExporter]

When a json object contains an explicit null for a field, the custom
deserializer for that field type is never called, rather the field is
simply set to null. This makes it impossible to map json nulls to some
non-null value in a consistent way. It also makes it impossible to have
guaranteed non-null fields in objects which are deserialized from json.

The handling of explicit nulls and missing values is also inconsistent: in
the case of an explicit null, the Java object's field is set to null. In
the case of a missing value, the field is left alone (as initialized by the
no-arg constructor).

The behavior for missing values is reasonable, but the behavior for
explicit nulls is very difficult to work around. Explicit null values
should (perhaps optionally) be passed through the custom deserializer.

What steps will reproduce the problem?
1. compile the attached file
2. run it

What is the expected output? What do you see instead?
Expected output:
  NullInner should equal NullInner
  NullInner should equal NullInner
OR:
  NullInner should equal NullInner
  InitInner should equal NullInner
I see:
  null should equal NullInner
  InitInner should equal NullInner

What version of the product are you using? On what operating system?
gson 1.4

Original issue reported on code.google.com by hell...@gmail.com on 3 Nov 2009 at 11:33

Attachments:

• Main.java

[GoogleCodeExporter]

We thought about providing that support, but doing so will break existing 
deserializers since now they will have to do a check for JsonNulls. We couldn't 
think 
of a backward compatible way of solving this problem. 

What is the problem that you are trying to solve. Will a postConstruct method 
do the 
job?

Original comment by inder123 on 8 Jan 2010 at 7:24

[GoogleCodeExporter]

Sorry for the very long delay. The problem we were trying to solve here is 
mapping json values to scala Option 
values. Rather than null, a missing value should be mapped to the distinguished 
None value, while any value 
will be Some(blah). (Of course, this pattern is useful in many cases other than 
Option, and not just in Scala: 
anytime one would like to avoid nulls.)

A postConstruct method would probably do the job, but it still feels very dirty 
to allow the assignment to null 
and then check for it in a second pass. This is effectively what I've had to do 
now, and it works, but I find it 
pretty unsatisfying.

My preference would be to *optionally* expose the JsonNulls to the 
deserializers, controlled by a setting on 
GsonBuilder, I suppose. The standard deserializers could easily be changed to 
deal with this, and users would 
only have to update their deserializers if they wanted access to explicit 
nulls. 

Original comment by hell...@gmail.com on 15 May 2010 at 2:37

[GoogleCodeExporter]

Original comment by limpbizkit on 3 Nov 2010 at 4:55

• Added labels: Milestone-Undefined, Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

We don't have this problem with TypeAdapterFactory-registered TypeAdapters. 
Using those allow you to do whatever you want with null in either direction.

This is in Gson 2.1.

Original comment by limpbizkit on 30 Dec 2011 at 6:43

• Changed state: Fixed