Reflect well-known MediaTypes intent in Javadoc

[ghillert]

It is 2024 and I think the MediaType class should add several of the more common image-related mime-types such as:

• image/webp
• image/avif
• image/svg+xml

I know there are a ton of mime-types out there, but Spring Framework should add a few of the ones that have become quite common recently. Seeing only GIF, JPEG and PNG in the list feels rather old-school. This would be quite convenient, also, when building a ResponseEntity.

For reference: there was an old issue from 2018 that was closed: #18446

[ThomasVitale]

This is really perfect timing! Working on Spring AI, we hit the limits of the MediaType and MediaTypeUtils classes as well (I raised this issue just a few hours ago: spring-projects/spring-ai#1562). In particular, due to missing media types for audio content when working with large language models consuming or producing audio. I wonder if they could be also considered as part of this feature request.

[sdeleuze]

We will discuss that within the team and provide a feedback.

[bclozel]

Our general policy leans towards accepting new static values there only for media types that are used by the Spring Framework or a module integration. If anything, I'm not sure the "image/*" types already listed are really useful. They're not being used in the "spring-projects" org, besides in tests.

I think a fair comparison would be Spring HATEOAS, which needs and supports specific media types. They're declared in a dedicated class and co-located with the code that supports them.

We've had numerous requests asking to add new entries there, I think this comes from a perspective where adding a media type there makes it somewhat official in the Spring ecosystem, whereas we expect MediaType to be used to create those instances where the support is implemented.

I think we should revisit the values currently listed in MediaType and consider deprecating/removing for the next major version. Stating a cleear rule and enforcing it for values that don't align with it should help in the long term. Without that, all Spring applications will load instances of media types they'll most likely never use.

[bclozel]

We discussed this as a team today and decided the following:

• we want to better reflect in the Javadoc the fact that well-known types in MediaType are here because they're maintained along specific support in Spring Framework. We do not want to support new types unless they're being used actively in the Spring Framework codebase
• as a result, we will not introduce new "image/*" types in MediaType
• after reviewing existing well-known instances, we've seen a few that do not qualify but they've been around so long that we won't consider removing them at this time

I'm turning this issue into a documentation issue; we should update the MediaType javadoc to explain this situation and let developers know that they should create their own instances.