Allow to suppress null values in serialization #51

Activity

1. robinjhector commented on Feb 24, 2023

   

   robinjhector

   on Feb 24, 2023

   More actions

   To give a concrete example, imagine I have a business model such as:

   public record Person(String firstName, String lastName, String bio, String title, Country country) {}

   I would then map that to my api model such as:

   public static PersonApiModel fromBusinessModel(Person person) {
       return new PersonApiModel()
           .firstName(person.firstName())
           .lastName(person.lastName())
           .bio(person.bio())
           .title(person.title())
           .country(person.country());
   }

   If I for instance allow nulls for bio, title, and country, this would result in the Api model setter being called with explicit null. Which in turn would become a JsonNullable.of(null), and be serialized with literal nulls.

   Like @Ironlink said, I have a bunch of these properties, and we would ideally not want to rewrite all of our business->api conversions with the following pattern:

   var apiModel = new PersonApiModel()
       .firstName(person.firstName())
       .lastName(person.lastName());
   if (person.bio() != null) {
       apiModel.bio(person.bio());
   }
   if (person.title() != null) {
       apiModel.title(person.title());
   }

   ... etc for every possible field that can be null in java.
2. nrayburn-tech commented on Sep 26, 2025

   

   nrayburn-tech

   on Sep 26, 2025

   Last edited by nrayburn-tech

   Contributor

   More actions

   The difference between a property in the JSON and a property not in the JSON can be relevant based on your API design.

   However if you don’t care about that, then you don’t have to use a JsonNullable to begin with. You can just use the regular class and configure Jackson to not include nulls.
   For example, if you’re returning all of this data from something like a read endpoint then it doesn’t typically matter. However, if you’re using this data for a partial update to your entity then it might matter.

   So if I’m understanding the use case correctly, my suggestion is to not use JsonNullable<T> here. Just use T directly.

   (I know the issue is old and you two have likely moved on or solved this somehow, I’m just trying to clean up open issues.)
3. Ironlink commented on Nov 27, 2025

   

   Ironlink

   on Nov 27, 2025

   Author

   More actions

   We have tens of thousands of lines of OpenAPI models, and rely heavily on JsonNullable to implement partial updates. We are not interested in having JsonNullable in response models, but due to the sheer size of our specs we have chosen to share models between requests and responses. This means that EditPersonRequest and GetPersonResponse both reference the same shared model Person, which uses nullable: true to allow the client to send only the property they want to change in an EditPersonRequest.

   We then have two choices to trim null values from responses, either duplicate lots of spec with nullable: false or litter the server code with conditions to make the fields JsonNullable.undefined().

   I recognise that others may be relying on JsonNullable's current behaviour for output, and do not want to cause breakage. An option could look something like this:

   new JsonNullableModule().allowSuppressNulls(true)

   If this is agreeable, I can provide a PR.