Affects: 5 and 6

Currently about MediaType javadoc - for APPLICATION_JSON_UTF8 and APPLICATION_JSON_UTF8_VALUE - both are deprecated according with the following description for each one respectively:

Deprecated.
as of 5.2 in favor of APPLICATION_JSON 
since major browsers like Chrome now comply with the specification and interpret correctly UTF-8 special characters 
without requiring a charset=UTF-8 parameter.

Deprecated.
as of 5.2 in favor of APPLICATION_JSON_VALUE 
since major browsers like Chrome now comply with the specification and interpret correctly UTF-8 special characters 
without requiring a charset=UTF-8 parameter.

Even assuming if this situation applies perfectly to all the web browsers around the globe

  • What about when the client is a programmatic type? It about REST such as RestTemplate

Because my native speaking is Spanish - is normal have data with ñ and others such as é á ó

Therefore was normal use APPLICATION_JSON_UTF8 or APPLICATION_JSON_UTF8_VALUE according the case at:

  • For the @Controller - either @RequestMapping - or @GetMapping with the produces attribute and @PostMapping/@PutMapping with the consumes attribute - where is possible use MediaType
  • RestTemplate programmatic configuration through RequestEntity.HeadersBuilder with accept(MediaType... acceptableMediaTypes) and ResponseEntity.BodyBuilder with contentType(MediaType contentType).

So is not clear how now should be configured UTF-8 to be handle/support by programmatic clients for rest.

Comment From: bclozel

This media type variant was introduced because some browsers were not using UTF-8 by default. As stated in the discussion with you at the time, Sebastien pointed out that UTF-8 is the default anyway.

It's been deprecated later in #22788 because that advice was no longer relevant. I don't think it's ever been required to enforce the charset for other types of clients. If a server returns non-UTF8 content to your client, there's probably a bug on the server side.

Could you explain what's triggering this issue now? Is there a specific problem you can share, can you share a sample Spring application misbehaving in some way?

Comment From: manueljordan

If a server returns non-UTF8 content to your client, there's probably a bug on the server side.

If exists the scenario where a default infrastructure configuration for UTF-8 was created for either SF or SB, therefore the MediaType use has no sense - but if it does not exist therefore is assumed that for a Web/Rest controller uses the produces and consumes attributes to enter in action to work with JSON with UTF-8 - Am I correct, right?

I assume the same scenario for accept(MediaType... acceptableMediaTypes) and contentType(MediaType contentType)

Could you explain what's triggering this issue now? Is there a specific problem you can share, can you share a sample Spring application misbehaving in some way?

I remember that was mandatory for some SF apps (old releases) based on web (HTML) and rest - define for JSON the JSON-UTF-8 combination ... now according with the current javadoc it is already solved for web(HTML) but what about rest?

Comment From: bclozel

It's always been about some specific browsers, never about other types of clients. In that sense, there is no need to mention them in the javadoc as it would just confuse developers. The deprecation warning is quite clear: don't use this anymore and use the variant without the Charest from now on, in all cases.