[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] [13] RFR 8222108: Reduce minRefreshTime for updating remote printer list on Win
From:       Alexey Ivanov <alexey.ivanov () oracle ! com>
Date:       2019-06-25 19:17:41
Message-ID: b303bcbb-305e-4e48-2592-afb94e53845c () oracle ! com
[Download RAW message or body]

Please see the updated webrev:
http://cr.openjdk.java.net/~aivanov/8222108/webrev.01/

On 25/06/2019 00:01, Sergey Bylokhov wrote:
> On 24/06/2019 14:50, Alexey Ivanov wrote:
>>> 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*.
>
> That was an assumption on how it should work, but it was implemented 
> differently.

I see.

>> 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.
> I do not know, if it is always has the same order then the fix look 
> fine, if we unsure then probably we can tweak it and sort.

The order in which printers are enumerated by EnumPrinters is 
unspecified. For level 4, the information is queried from the registry. 
The order for registry enum functions is not guaranteed either. Even 
though the order of printers has always been the same so far, we cannot 
rely on this fact.

-- 
Regards,
Alexey
[prev in list] [next in list] [prev in thread] [next in thread]