On Friday, August 15, 2014, Bill Shannon <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)
>
>
> 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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>>>>
>>>
>>>
>>
>
>