[OpenJDK 2D-Dev] [9] RFR JDK-8025439: [TEST BUG] [macosx] PrintServiceLookup.lookupPrintServices doesn't work properly since jdk8b105

Philip Race philip.race at oracle.com
Wed Nov 30 16:46:00 UTC 2016


+1

-phil.

On 11/30/16, 2:19 AM, Prasanta Sadhukhan wrote:
> Please find the modifed the webrev as per review comments
> http://cr.openjdk.java.net/~psadhukhan/8025439/webrev.02/
>
> Regards
> Prasanta
> On 11/30/2016 1:04 AM, Phil Race wrote:
>> Leaving aside platform printer naming conventions and the like, it 
>> seems that
>> PrintService.getName() returns "Rich Aficio" but then when
>> the test does new PrinterName("Rich Aficio") and try to locate a printer
>> with that name it says "no such printer" ?
>>
>> Yes, that is possible since PrinterName is allowed to be different 
>> than PrintService.getName() :-
>> https://docs.oracle.com/javase/8/docs/api/javax/print/PrintService.html#getName--
>> so this strictly a test bug.
>>
>> So it seems to me that what the test should be doing is
>> querying the PrinterName attribute on the service and then
>> using the string obtained from there to initialise the PrinterName
>> used in the lookup.
>>
>> -phil.
>>
>>
>> On 11/16/2016 12:53 AM, Ajit Ghaisas wrote:
>>>
>>> The test should not worry about linux/solaris future change. If 
>>> there is any change, we will get to know with test failure.
>>>
>>> Change is OK.
>>>
>>> Please update the year in banner & add this bug id in jtreg @bug tag 
>>> before pushing.
>>>
>>> Regards,
>>>
>>> Ajit
>>>
>>> *From:*Prasanta Sadhukhan
>>> *Sent:* Wednesday, November 16, 2016 11:55 AM
>>> *To:* Ajit Ghaisas; Philip Race; 2d-dev
>>> *Subject:* Re: [OpenJDK 2D-Dev] [9] RFR JDK-8025439: [TEST BUG] 
>>> [macosx] PrintServiceLookup.lookupPrintServices doesn't work 
>>> properly since jdk8b105
>>>
>>> It can be done that way and it will solve this specific problem but 
>>> I did !Windows because even though linux/solaris GUI does not 
>>> support spaces as of now, GUI is easy to change and can accomodate 
>>> spaces in near future
>>> but CUPS library will not accomodate the spaces so it might fail in 
>>> linux/solaris then.
>>> Anyways, I am ok with making this mac specific
>>> http://cr.openjdk.java.net/~psadhukhan/8025439/webrev.01/ 
>>> <http://cr.openjdk.java.net/%7Epsadhukhan/8025439/webrev.01/>
>>>
>>> Regards
>>> Prasanta
>>>
>>> On 11/15/2016 4:11 PM, Ajit Ghaisas wrote:
>>>
>>>     If we know that exceptional behavior (service name containing
>>>     spaces) is only limited to Mac, then the check in test should be
>>>     only Mac specific and not (!windows).
>>>
>>>     Regards,
>>>
>>>     Ajit
>>>
>>>     *From:*Prasanta Sadhukhan
>>>     *Sent:* Tuesday, November 15, 2016 12:32 PM
>>>     *To:* Phil Race; 2d-dev
>>>     *Subject:* Re: [OpenJDK 2D-Dev] [9] RFR JDK-8025439: [TEST BUG]
>>>     [macosx] PrintServiceLookup.lookupPrintServices doesn't work
>>>     properly since jdk8b105
>>>
>>>     On 11/15/2016 4:39 AM, Phil Race wrote:
>>>
>>>         This evaluation needs to go in the bug report, not (just) here.
>>>
>>>         mac. shows spaces in the name in its GUI but "_" in the
>>>         names reported by lpstat
>>>         so it may be that the replacement is right but I'd still
>>>         like to dig a bit here.
>>>         Can you point to the code that does the " "->"_"
>>>         replacement. I can't see it
>>>         in CUPSPrinter.getAllPrinters().
>>>
>>>     As per
>>>     http://hg.openjdk.java.net/jdk9/client/jdk/file/449518f6a468/src/java.desktop/unix/classes/sun/print/CUPSPrinter.java#l425
>>>     it gets the response from CUPS server and the printer names
>>>     obtained from server is stored in jdk. In my case, even though I
>>>     specified "Ricoh Aficio..." in GUI
>>>     the "nameStr" obtained from CUPS responseMap is "Ricoh_Aficio..."
>>>
>>>
>>>         And you saying that
>>>
>>>         PrintServiceLookup.lookupPrintServices(null, null)
>>>
>>>         will return an array with a "null" element ?
>>>
>>>     No, sorry to "eat-up words". What I meant to say,
>>>     lookupPrintServices(null, attributes) returns array with 0
>>>     elements as checkPrinterName() return false [as user is asking
>>>     to find "Ricoh Aficio" and not "Ricoh_Aficio"]
>>>     resulting in getServiceByName() returning null
>>>     which in turn causes lookByName() in the testcase to return null
>>>
>>>     Regards
>>>
>>>     Prasanta
>>>
>>>         That would be a bug.
>>>
>>>         -phil.
>>>
>>>         On 11/14/2016 02:18 AM, Prasanta Sadhukhan wrote:
>>>
>>>             Hi All,
>>>
>>>             Please review a small bugfix whereby it is seen that if
>>>             we specify printer with space in its name, then
>>>             javax/print/PrintServiceLookup/GetPrintServices.java
>>>             fails citing NPE.
>>>
>>>             Bug: https://bugs.openjdk.java.net/browse/JDK-8025439
>>>             webrev:
>>>             http://cr.openjdk.java.net/~psadhukhan/8025439/webrev.00/ <http://cr.openjdk.java.net/%7Epsadhukhan/8025439/webrev.00/>
>>>
>>>             The NPE happens because
>>>             http://hg.openjdk.java.net/jdk9/client/jdk/file/b1543c5eb8af/src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java#l460
>>>             calls checkPrinterName() which checks it name contains
>>>             letter or digit
>>>             http://hg.openjdk.java.net/jdk9/client/jdk/file/b1543c5eb8af/src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java#l433
>>>             and returns null if has spaces
>>>             so lookupPrintServices() gets null
>>>
>>>             Now, if we remove this <space> check then also, it will
>>>             not work as
>>>             In system running with CUPS, refreshServices calls
>>>             CUPSPrinter#getAllPrinters() which returns a set of
>>>             printers. It seems it replaces " "  with "_" when
>>>             populating the list
>>>             for e.g Ricoh Aficio MP 5002 printer name is sent as
>>>             Ricoh_Aficio_MP_5002 and stored in the list so we cannot
>>>             have <space> in printer name.
>>>
>>>             In Mac, it takes <sp> in printer name when we add
>>>             printers but in linux, solaris it does not allow spaces
>>>             in printer name during addition
>>>             so in the proposed fix, a check for <sp> is added to
>>>             make it automatic pass for non-windows (CUPS) system.
>>>
>>>             Regards
>>>             Prasanta
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20161130/5b0eef95/attachment.html>


More information about the 2d-dev mailing list