[jsr372-experts] Re: Parameterize Converter and Validator interfaces

From: Bauke Scholtz <balusc_at_gmail.com>
Date: Thu, 25 Jun 2015 22:54:29 +0200


I parameterized the interfaces in our repo last week. When I came to the
step of parameterizing the now raw-typed standard converter
implementations, I see the below check in getAsString of ALL standard
javax.faces.convert.* converters:

// If the incoming value is still a string, play nice

// and return the value unmodified

if (value instanceof String) {

  return (String) value;


What is this? Is this a leftover of JSF 1.x? I'd opt for removing them all,
but this would induce less backwards compatibility (although I'd really
wonder who would explicitly specify those converters on a String model
type). If we really need to keep them, then e.g. IntegerConverter can't be
parameterized with <Integer> without triggering a compile error on
incompatible types on that check. We would then end up with an
IntegerConverter which implements Converter<Object> which just isn't nice
to the outside world.

Cheers, B

On Fri, Jan 30, 2015 at 7:54 PM, manfred riem <manfred.riem_at_oracle.com>

> Hi Bauke,
> Are you willing to get this one done and create the appropriate test
> coverage showing that
> a) that it indeed does not break existing converters / validators
> b) that the new behavior works
> Thanks!
> Manfred
> On 1/30/15, 6:10 AM, Bauke Scholtz wrote:
> Hi,
> In the mailing list subject "[NEW] Converter chaining,
> global converters" I have proposed to parameterize Converter and Validator
> interfaces so that Object can be replaced by T which should reduce casting
> boilerplate in basically all custom converters and validators. I'd like
> to see the spec being changed on this. This change does not break
> existing converters and validators. It'll at most generate a warning on raw
> types.
> Does anyone have objections on this?
> Cheers, Bauke