Given that there probably isn't much call for injection or dynamic state
in these converters, a provider could just keep a single instance around
to use for all of its conversions of that type, right?
On 13/01/2012 11:35 AM, Pinaki Poddar wrote:
>> Why would it need to be static?
> I did not mean that it *must* be static. Having a mechanics to *also*
> invoke static method of a user-supplied implementation for conversion will
> have some runtime benefit (e.g. less instantiation of the converter
> instances).
>
> Regards --
>
> Pinaki Poddar
> Chair, Apache OpenJPA Project http://openjpa.apache.org/
> JPA Expert Group Member
> Application& Integration Middleware
>
>
>
>
>
>
>
>
> From: michael keith<michael.keith_at_oracle.com>
> To: jsr338-experts_at_jpa-spec.java.net
> Cc: Pinaki Poddar/Dallas/IBM_at_IBMUS
> Date: 01/13/2012 07:53 AM
> Subject: [jsr338-experts] Re: mapping conversion
>
>
>
> On 12/01/2012 1:04 PM, Pinaki Poddar wrote:
>> 1. On the queries section, it may be worthwhile to mention that the
> binding
>> parameters or projected terms referring to a converted attribute are of
>> type<X> i.e. the type of the attribute.
> Sure, this feature will need some coverage in the queries section,
> including parameter binding.
>> 2. It may be useful to allow static method of a "converter" class be
>> invoked for conversion. Typical conversion (e.g. boolean to integer) can
>> then be handled more centrally/uniformly.
> Why would it need to be static? Applications can instantiate their own
> concrete class and use it for conversion of anything they want if they
> need to do so.
>
>
>
>