Hi,
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>
wrote:
> 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
>
>