Hi Sergey,
On 18/06/2019 21:37, Sergey Bylokhov wrote:
Hi, Alexey.
I guess that the change in doCompare() passed a review because it was
assumed that the code inside will take care of unordered arrays. if we
will drop the doCompare() then probably we need to sort the content of
the arrays before Arrays.equals()?
I can't see where doCompare() handled unordered arrays; quite the
opposite: doCompare(new String[]{"a", "b"}, new String[]{"a", "b"})
returns true (that is the arrays are *not equal*) whereas the arrays are
*equal*.
While I run the test, the list of printers always has the same order. We
do not sort the array returned by getAllPrinterNames() in
PrintServiceLookupProvider.refreshServices(), so I assume Windows
returns the installed printers in the same order. Therefore I think
sorting the array is not necessary in this case.
On 14/06/2019 11:07, Alexey Ivanov wrote:
Hi,
Please review the following fix for JDK 13:
bug: https://bugs.openjdk.java.net/browse/JDK-8222108
webrev: http://cr.openjdk.java.net/~aivanov/8222108/webrev.00/
The main goal of this bug was to reduce the minimum refresh time for
updating remote printer list to facilitate testing.
While working on this bug, I've also done some refactoring. The most
prominent one is replacing doCompare() with Arrays.equals(). The
former gives wrong result for equal arrays if the array length is
greater than 2. Thus this bug can be considered as regression.
Arrays.equals() accepts null parameters and null elements in the
arrays and always returns the correct result.
--
Regards,
Alexey
