users@javaee-spec.java.net

[javaee-spec users] Re: Consolidation of Type Conversion

From: Martijn Verburg <martijnverburg_at_gmail.com>
Date: Thu, 7 Aug 2014 13:43:23 +0100

+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.

Cheers,
Martijn


On 7 August 2014 04:24, Reza Rahman <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
>>
>
>