RFR 8187359: JShell: Give comprehensible error when user method name matches Object method

Jan Lahoda jan.lahoda at oracle.com
Thu Oct 19 16:00:03 UTC 2017


On 14.10.2017 23:09, Robert Field wrote:
> Thanks Jan!
>
> Coming back to this, post repo consolidation, I see this is
> unnecessarily restrictive, the error occurs only when the signatures
> match as well.   Ideally we want users to never see this error, so
> making it less common is good.  I've changed the new error to only
> appear when it would have failed (with a confusing error).  Now methods
> like:
>
>      boolean equals(foo f1, Foo f2) ...
>
> would be allowed.

I was thinking of that on the first review. But declaring such (top 
level) methods does not seem very useful. Unless I am mistaken, there is 
no good way to use them:
---
jshell> boolean equals(int i1, int i2)  { return i1 == i2; }
|  created method equals(int,int)

jshell> equals(1, 2)
|  Error:
|  method equals in class java.lang.Object cannot be applied to given types;
|    required: java.lang.Object
|    found: int,int
|    reason: actual and formal argument lists differ in length
|  equals(1, 2)
|  ^----^
---

So, I didn't mind the approach where such methods were rejected.

Jan

>
> The code remains the same in concept but is distributed differently --
> switching out diagnostics after compilation.
>
> And a corresponding update and additions to the tests.
>
> Updated webrev:
>
>       http://cr.openjdk.java.net/~rfield/8187359v3.webrev/
>
> -Robert
>
> On 09/12/17 12:50, Jan Lahoda wrote:
>> Seems OK.
>>
>> Jan
>>
>> On 8.9.2017 07:38, Robert Field wrote:
>>> Please review.
>>>
>>> Bug:
>>>
>>>      https://bugs.openjdk.java.net/browse/JDK-8187359
>>>
>>> Webrev:
>>>
>>>      http://cr.openjdk.java.net/~rfield/8187359v0.webrev/
>>>
>>> Thanks,
>>> Robert
>>>
>


More information about the kulla-dev mailing list