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

From: arjan tijms <>
Date: Thu, 7 Aug 2014 10:02:43 +0200


You're right and incidentally just a short while ago I discussed the exact
same thing with the JSF co-spec lead (Manfred) and started a draft article
about this, but unfortunately did not yet get around to publish it.

Indeed, there are many specs all defining their own converters. Some use
generics for general S to T conversion, while others are String to Object
and reverse only. If there was a platform wide conversion API available
(like there is for validation) then I'm pretty sure at least JSF would
surely be among the first to use this.

Kind regards,

On Thursday, August 7, 2014, 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