Proxy.isProxyClass scalability

[Peter Levart]

On 04/23/2013 05:27 AM, Mandy Chung wrote:
>
> On 4/21/2013 6:39 AM, Peter Levart wrote:
>> On 04/21/2013 04:52 AM, Mandy Chung wrote:
>>> Hi Peter,
>>>
>>> I want to give it some more thought and discuss with you next week.  
>>> As for the zero number of interface, I think it's a bug and it 
>>> should throw IAE if the given interfaces array is empty.   Thanks 
>>> for finding it and I'll file a separate bug for that since it 
>>> requires spec update/clarification.
>>
>> I think it's a feature. It's useful, since it forwards Object methods 
>> to InvocationHandler (equals, hashCode, ...). Sometimes that's all 
>> you need.
>>
>
> Do you have specific use case or know any existing applications doing 
> that?  What's the reason one would  prefer to create a proxy class 
> with InvocationHandler rather than defining its own class that 
> implements equals, hashCode, or toString() method?

I really don't have a use-case here. I can only think of a hypothetical 
case where one would already have an InvocationHandler capable of 
serving proxies for various interfaces, including equals/hashCode 
methods. Now to be able to re-use that logic for constructing keys for 
Maps, one could simply request a proxy with no interfaces. The fact is 
that currently this is allowed and although there might not be any 
usages, it doesn't hurt to allow it in the future and there's no 
performance cost supporting it. I think that not putting artificial 
constraints on API usage without a reason is a good design. It's similar 
in a way to some things in language, like for example the support for 
empty arrays. Why would anyone want to have an empty array?

Regards, Peter

P.S. What do you think of the latest webrev? I did some further 
simplifications to code (removed checks for reverseMap != null) and 
re-worded some javadocs. I can publish another webrev together with 
possible further changes when you review it.

>
> Mandy