You missed the JavaBeans Activation Framework, which is built on the AWT data
transfer APIs and does Object to/from MIME byte stream conversions.
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. 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?
arjan tijms wrote on 08/07/2014 11:10 AM:
> On Thu, Aug 7, 2014 at 2:43 PM, Martijn Verburg <martijnverburg_at_gmail.com
> <mailto:martijnverburg_at_gmail.com>> wrote:
>
> +1 to this - it needs a strawman doc for the various spec leads to discuss
> around. Great thinking BTW - it would be good to have a unifier for this.
>
>
> I just published my article about this subject, it's at:
> http://arjan-tijms.blogspot.com/2014/08/high-time-to-standardize-java-ee.html
>
> Hopefully this will be a good starting point for further discussion.
>
> Kind regards,
> Arjan Tijms
>
>
>
> Cheers,
> Martijn
>
>
> On 7 August 2014 04:24, Reza Rahman <Reza.Rahman_at_oracle.com
> <mailto:Reza.Rahman_at_oracle.com>> wrote:
>
> I think the best course of action is to write up a detailed proposal
> in JIRA.
>
>
> On 8/6/2014 10:58 PM, John D. Ament wrote:
>
> Hi all,
>
> So in the last few days, i've pulled out what I would consider to
> be the last of my short hair dealing with type conversion in Java
> EE 7. In my project, I'm using JPA 2.1, JAX-RS 2.0 and WebSockets
> 1.0. In my use case, I have some POJOs that I pass around those
> three layers via JSON. In each of these, I have to worry about
> the type conversion requirements of each of them, specifically
>
> JPA leverages an AttributeConverter
> WebSockets use Encoder/Decoder's
> JAX-RS uses MessageBodyReader/Writer
>
> In two of these, it gets a little more confusing as I have to
> implement different interfaces for reading and writing. In total
> I need to implement 5 different interfaces, some of which support
> CDI injection and others that do not.
>
> In addition, if you look across the Java EE spectrum, we have
> additional ways in which type conversion is supported.
>
> JMS 2.0 added support for implicit body reading when getting a
> message and new ways to create messages from some POJOs.
> - We did not add support a serialization process other than
> reconfirming that ObjectMessage requires a Serializable object.
>
> JSF has a Converter interface
>
> I'm sure there are other use cases as well. I'd like to propose
> that the entire platform needs to consolidate down to a single way
> of converting objects, arbitrarily. Then allow each of these
> specs to build from that conversion going forward.
>
> I'm not sure the right course of action. Should this become a
> ticket for this spec? Does something like this require an
> enhancement specification by itself?
>
> Thanks,
>
> John
>
>
>
>