[8u] RFR 8214687: Optimize Collections.nCopies().hashCode() and equals()

[Aleksey Shipilev]

On 7/31/19 5:56 PM, Andrew John Hughes wrote:
> On 31/07/2019 10:02, Aleksey Shipilev wrote:
>> On 7/16/19 9:25 AM, Andrew John Hughes wrote:
>>> On 15/07/2019 09:27, Aleksey Shipilev wrote:
>>>> On 7/2/19 9:53 PM, Aleksey Shipilev wrote:
>>>>> Original RFE:
>>>>>   https://bugs.openjdk.java.net/browse/JDK-8214687
>>>>>   https://hg.openjdk.java.net/jdk/jdk/rev/cfceb4df2499
>>>>>
>>>>> Patch applies with usual reshufflings. But the test parts require touchups to compile and run on 8u:
>>>>> type inference is not that rich, and there is no Objects.checkIndex. 8u webrev:
>>>>>   https://cr.openjdk.java.net/~shade/8214687/webrev.8u.01/
>>>
>>> Objects.checkIndex is simply a wrapper around Preconditions.checkIndex:
>>>
>>>     public static
>>>     int checkIndex(int index, int length) {
>>>         return Preconditions.checkIndex(index, length, null);
>>>     }
>>>
>>> which is in 8u. Probably worth adding the 2-argument version to
>>> Preconditions.
>>
>> Getting back to this. Since we have moved Preconditions to private location in 8u, using it is
>> impossible for this patch. So, I would keep the webrev as is:
>>   https://cr.openjdk.java.net/~shade/8214687/webrev.8u.01
> 
> We haven't moved anything as yet and my proposed patch leaves the class
> as public, so shouldn't be a blocker. The test in that patch uses
> Preconditions.

Original patch needs Objects.checkIndex:
  https://hg.openjdk.java.net/jdk/jdk/rev/cfceb4df2499#l2.32

What you are suggesting is changing that line to Preconditions (with new method!). What webrev
suggests is replacing it with the one-liner:

  91  check(0 <= index && index < n, "Index is incorrect");

Given that we are changing the code anyway, I don't see why do we need to introduce another
dependency to the about-to-be-moved class, do more code that diverges 8u from later releases,
instead of doing the trivial one-liner.

>> It is approved for 8u and 11u push, so if there are no other comments, I would push the fix shortly.
>>
> 
> Please don't "timeout" patches. Someone not seeing an e-mail is not the
> same as an ok.

Err. I meant to say that if there is no other comments, I am willing to move forward with this patch
fast. It had been stuck on my queue for too long :)

-- 
Thanks,
-Aleksey