I assumed that the original designers were enforcing the idea that
Renderers are an implementation detail and not required, however I agree
that the distinction isn't especially important--returning null is
plenty fine.
The lame part is that simply making getRenderer() public would be an
incompatible change at this point, so we are stuck adding something like
this to UIComponent:
public final Renderer reallyGetRenderer()
{
return getRenderer();
}
-- Blake Sullivan
On 4/3/12 7:30 AM, Edward Burns wrote:
>>>>>> On Mon, 2 Apr 2012 12:15:24 -0400, Kito Mann<kito.mann_at_virtua.com> said:
> KM> On Mon, Mar 5, 2012 at 9:53 AM, Edward Burns<edward.burns_at_oracle.com>wrote:
>>>>>>>> On Mon, 5 Mar 2012 09:31:59 -0500, Kito Mann<kito.mann_at_virtua.com>
>>> said:
>>>
> KM> Is there any reason UIComponent.getRenderer() is protected instead of
> KM> public? It'd be nice if it were public, especially when writing test
> KM> code.
>
> EB> Just your garden variety information hiding principles. Does anyone
> EB> else want this? It seems a pity to add a new public method just for
> EB> testing purposes. At this point, we must undertake the addition of new
> EB> API with the greatest care and moderation.
> EB>
>
> KM> Understood, but why does this information need to be hidden?
>
> I would have to do some list forensics to uncover that. Do you think
> it's worth our time to research that?
>
> Ed
>