Proxy.isProxyClass scalability

[Mandy Chung]

On 4/22/2013 11:24 PM, Peter Levart wrote:
> 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. 

I can't say for sure allowing to define a proxy class with no interface 
is a good design and thus I propose to file a separate issue to follow 
up and determine if there is any issue with and without such constraint 
(interfaces.length() > 0 or not).  Yes - I am in a position not to allow 
creating a proxy class with no interface since that was not the original 
use case (for RMI).  But I see your point and we need to investigate 
before we decide one way or the other.  If we determine no need to 
constraint that, we can close that bug as will not fix.

> 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?
>

I don't think the Proxy API can be compared with empty array language 
support :)

> 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.
>

Sorry I didn't get the chance to look at your past 2 webrevs (I was 
distracted with higher priority tasks).

Mandy

>>
>> Mandy
>