arjan tijms wrote on 08/15/14 07:36:
> On Friday, August 15, 2014, Bill Shannon <bill.shannon_at_oracle.com
> <mailto:bill.shannon_at_oracle.com>> wrote:
>
> You missed the JavaBeans Activation Framework, which is built on the AWT
> data transfer APIs and does Object to/from MIME byte stream conversions.
>
>
> Great suggestion! I'll look into doing an update.
>
>
> Yes, there's a lot of converters, and probably more than we need, but many
> of them exist because there are different requirements in each case. I
> don't just want Object to String, I want Object to String-containing-html
> or Object to String-containing-xml or Object to String-containing-JSON or
> Object to String-suitable-for-display-to-user or whatever.
>
>
> True, but there's overlap as well, and some seem to be doing directly the same
> thing such as the JSF and JAX-RS converters (both do request parameter to
> object and the other way).
>
> It's also a question whether a different String content should require a
> different API.
>
> Converting between Java types and MIME types handles many of these cases,
> but not all of them. I'm hoping that a future version of the JDK will
> have better MIME type support. Assuming we had it, can you imagine how to
> replace all these existing uses by something like that?
>
>
> Do you mean how to set up some kind of wrappers to adapt the universal
> converters to more specific specs? (Eg how bean validation was integrated with
> the existing JSF validators)
>
Right, or more generally how these "universal" converters could be used in each
of the specific cases where existing specs use converters. How do you handle
some of the special requirements that the existing converters support when using
these hypothetical universal converters with existing specs?
I do think that a more general converter mechanism could be used in many of
these cases, but I fear that there are still some spec-specific requirements
that would be hard to address with general converters, or would add complexity
to any general converter mechanism. If we ever get a proposal for a more
general converter support in the JDK, we would need to make sure that proposal
addressed the needs of our existing specs.