selectVariant not very useful

From: Bill Burke <>
Date: Thu, 30 Jul 2009 13:07:04 -0400

I hope you don't mind me telling you how ugly the selectVariant API is.
  I really can't seem myself ever using it, why?

* Content-encoding, in general, is not something you can do with JAX-RS
apis unless you want to do your own streaming.

* Content encoding is something you do, or not do and is completely
orthogonal to the media type and language.

* I can't, in practice, ever see the use case where a resource method
would support a language for one media type, and not another, at least
where a JAX-RS service is concerned.

* In most JAX-RS services, the response media-type is automatically
chosen based on return type, @Produces, and accept-header.

That being said, I think it would be more useful to add a
@ProduceLanguages annotation and a @AcceptLanguage annotation instead.
A lot less code. For example:

@Produces({"application/xml", "application/json"})
@ProduceLanguages({"en", "es"})
public Customer getCustomer(@AcceptLanguage Locale language) {

This is a lot simpler, less code, and easier to explain than:

@Produces({"application/xml", "application/json"})
public Customer getCustomer(@Context Request request) {
       Variant.VariantBuilder vb = Variant.VariantBuilder.newInstance();
       vb.languages(new Locale(“en”), new Locale(“es”));
       Variant v = request.selectVariant(;
       Locale language = v.getLanguage();


Even just using HttpHeaders.getAcceptableLanguages() is better if you
didn't want to add the additional dispatching logic and annotations.

I strongly suggest we deprecate the Variant API and prune it in a later
versions of the specification.

Bill Burke
JBoss, a division of Red Hat