[OpenJDK 2D-Dev] [13] RFR 8222108: Reduce minRefreshTime for updating remote printer list on Windows

Philip Race philip.race at oracle.com
Tue Jul 2 23:13:33 UTC 2019


I thought we had the checks for null in doCompare there for a reason.
Arrays.sort won't be very happy with a null element.

You said in the first review email of the v0 webrev :

 > Arrays.equals() accepts null parameters and null elements in the 
arrays and always returns the correct result.

but that webrev didn't use Arrays.sort and that requirement seems to 
have been forgotten
when adding it.

  public class Sort {
   public static void main(String[] args) {
     String[] a1 = { "a", null, "a" };
     java.util.Arrays.sort(a1);
   }
}

java Sort
Exception in thread "main" java.lang.NullPointerException
     at 
java.util.ComparableTimSort.countRunAndMakeAscending(ComparableTimSort.java:320)
     at java.util.ComparableTimSort.sort(ComparableTimSort.java:188)
     at java.util.Arrays.sort(Arrays.java:1246)
     at Sort.main(Sort.java:4)


-phil.

On 7/2/19, 5:18 AM, Alexey Ivanov wrote:
> Are there any other comments?
> Other volunteers for reviewing?
>
> Thanks in advance.
>
> On 25/06/2019 20:17, Alexey Ivanov wrote:
>> 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.


More information about the 2d-dev mailing list