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