Add Gson HttpMessageConverter [SPR-9488]

[spring-projects-issues]

Francisco Lozano opened SPR-9488 and commented

Gson is very useful also out of Android environment. We have Jackson by default in full Spring web, but it would be useful to be able to use the GsonHttpMessageConverter instead in Spring Web.

---

Affects: 3.1.1, 3.2 M1

Issue Links:

• Include GsonHttpMessageConverter in Spring MVC [SPR-11460] #16086 Include GsonHttpMessageConverter in Spring MVC
• AllEncompassingFormHttpMessageConverter does not prefer Jackson2 over JAXB for XML marshalling [SPR-13240] #17831 AllEncompassingFormHttpMessageConverter does not prefer Jackson2 over JAXB for XML marshalling

Referenced from: commits 22a38d4, 64bb308, e3a6fce, 811330f

3 votes, 9 watchers

[spring-projects-issues]

Rossen Stoyanchev commented

To aid the discussion would you mind mentioning your specific reasons for looking to use it over Jackson.

[spring-projects-issues]

Francisco Lozano commented

Sure.

Full spring Web uses Jackson for serializing entities, but Jackson is usually too heavy for Android environment, so in Spring for Android a Gson-based message converter is included [1]. This is great, but the lack of GsonHttpMessageConverter in full Spring Web is bad because forces you to maintain two serialization configuration for the same "DTOs": the Jackson annotations/mixins for the server and the Gson annotations/type converters for the android client. It feels very inconvenient.

Also, if you are creating a REST client library for a specific service (my case) and you'd like it to be compatible with both (Spring/Java RestTemplate and Spring/Android RestTemplate), it'd be great to have the same message converter available in both.

Spring for Android includes both (Jackson and Gson), so I think Spring Web could also include both, and let the developer decide. The code is already there (in Spring Android) anyway...

BTW: There's a nice feature also work backporting in Spring Android's RestTemplate: a constructor with a boolean flag which disables any preconfigured message converter and allows the developer to choose them all from the beginning, without any default. (Is this worth another JIRA?).

[1] http://static.springsource.org/autorepo/docs/spring-android/1.0.0.RELEASE/reference/html/rest-template.html#d4e61

[spring-projects-issues]

Roy Clarkson commented

As Francisco stated, I added Gson support in Spring for Android because Gson is a smaller dependency and would result in a smaller app. It's worth noting, that Jackson is supposed to perform faster, although I have not independently verified this. Francisco makes a valid case for including Gson in Spring Web, as this would allow for object compatibility between server and client.

Francisco's last point is regarding ANDROID-88. I modified the RestTemplate constructors in Spring for Android to not include any message converters by default. Again, this was done for performance concerns on Android. One concrete reason for this was ANDROID-82. StringHttpMessageConverter called Charset.availableCharsets() in its constructor, which was reported to take a significant time on some Android environments. So now the default RestTemplate constructor does not create a StringHttpMessageConverter, or any other converters. That exercise is now left to the developer. However, you can include the standard set of converters if you chose, by passing "true" to the alternate RestTemplate constructor. If this functionality is desired in Spring Web, then this should be tracked in a separate JIRA.

[spring-projects-issues]

Rossen Stoyanchev commented

... disables any preconfigured message converter and allows the developer to choose them all from the beginning, without any default. (Is this worth another JIRA?).

I would prefer another constructor that accepts an HttpMessageConverter vararg over a boolean since booleans could become a problem if you ever needed something more than true or false or had another similar change to make. Feel free to create a new ticket.

As for the default charset in StringHttpMessageConverter, I've accepted #14122 for 3.2 M2.

What versions of Android had the time overhead in calling Charset.availableCharsets? I.e. is it trending towards going away or not? I would hesitate to add it if it has no functional purpose and it is added purely for performance reasons.

[spring-projects-issues]

Roy Clarkson commented

Craig Walls and I discussed some different options with the constructor, including using a vararg of message converters. I don't disagree with the potential issues of using a boolean. If you elect to use a different solution, I'll probably modify Spring for Android in a future release to stay consistent with Spring Web. I like to maintain parity where possible. I'm happy to discuss further.

Re. Android and Charset.availableCharsets. It was tested on Android 2.3.4 on a Galaxy S II. Android 2.3 is by far the most common version right now. This forum post has more information.

[spring-projects-issues]

Grzegorz Rozniecki commented

Any chance of backporting GsonHttpMessageConverter to core? I use it as an replacement for default Jackson converter in my Spring application and so far I have to maintain copy-pasted code from spring-android. It would be nice if JSON converter could be chosen between Jackson and Gson (with Jackson as default).

[spring-projects-issues]

Francisco Lozano commented

Any chance of this being revisited?

[spring-projects-issues]

Juergen Hoeller commented

Rossen, let's consider this for 4.1...

[spring-projects-issues]

Dominic Clifton commented

I would like to see this too. If I recall from a project I was involved in a couple of years back GSON was selected over Jackson because of the amount of objects Jackson creates which need garbage collecting, apparently GSON was better. That discussion happened before I joined the project and I'm just relaying second-hand unverified information here...

[spring-projects-issues]

Roy Clarkson commented

Rossen and Juergen, I'm working on a pull request with an updated version of the GSON message converter from Spring Android. I'll submit as soon as I can.

[spring-projects-issues]

Roy Clarkson commented

Submitted a pull request for this feature. #493