[OpenJDK 2D-Dev] RFR 6870661 : Setting a custom PrintService on a PrinterJob leads to a PrinterException

Phil Race philip.race at oracle.com
Mon Jun 17 21:51:52 UTC 2013

The superclass does check that the service will (claims to) support 

I've looked at what we did in the implementation when it comes to print 
is that for such a custom service we implicitly head it off to the 
javax.print API
so it probably could work.

But the dialog code probably does need to be tweaked to always invoke
the cross-platform dialog in this case. Right now its bailing from native
only if it sees a StreamPrintService.

So line 560 and maybe line 590 should be
if (!(service instanceof Win32PrintService)) ...

pageDialog() needs similar treatment.

Try those and see if you get sensible behaviour when showing the dialog.


On 6/17/2013 2:00 PM, Patrick Reinhart wrote:
> Hi Phil,
> What irritates me though is the fact, that there is no check for the 
> support/not support of 2D printing and also that the PrinterException 
> does not reflect the described cases of the spec:
> java.awt.print.PrinterException: Invalid name of PrintService.
> I can not see any relation to one of the referred cases of the spec:
> The spec. for PrinterJob.setPrintService() says :-
>> *Throws:*
>>    |PrinterException
>> <http://docs.oracle.com/javase/6/docs/api/java/awt/print/PrinterException.html>| 
>>    - if the specified service does not support 2D printing,
>>      or this PrinterJob class does not support setting a 2D print 
>> service,
>>    or the specified service is otherwise not a valid print service.
>> So an exception is expected.
>> If I understand your fix you want to change it so that WPrinterJob 
>> simply
>> doesn't go down to native so is less specific about what Service it will
>> accept? But WPrinterJob is completely tied to Win32PrintService
>> and windows native printing. The Windows print dialog for example
>> will  know nothing about your service.
>> So this seems like not a bug. You should just use javax.print APIs in 
>> this case.
> Well in my case I had the plan to capture the printer interaction for 
> testing reasons instead of using real printers. In my case a 3th party 
> product was using the setPrintService() method internally, where I did 
> not have the possibility of using the javax.print API in this case. 
> Also irritating was the fact, that under Linux the same method call 
> behaved not the same, in fact there it worked without any problem. 
> Also it seems to be no problem if the print service is of type 
> StreamPrintService where it does more or less the same as my supposed 
> fix. So it can not be tied that completely to the WIn32PrintService.
> Cheers Patrick
>> -phil.
>> On 6/15/2013 8:19 AM, Patrick Reinhart wrote:
>>> Could someone review my fix?
>>> http://reinharts.dyndns.org/6870661/webrev.00
>>> Cheers
>>> Patrick
>>> On 06/11/2013 10:32 PM, Patrick Reinhart wrote:
>>>> Hi Phil,
>>>> I just started looking into this Bug and have already written a 
>>>> test to prove a later fix though. As it seems that there missing 
>>>> two checks make sure, that the actual PrintService is a instance of 
>>>> W32PrintService  before passing it to the native method 
>>>> setNativePrintService()
>>>> Fix proposal for this bug is as follows:
>>>> http://reinharts.dyndns.org/6870661/webrev.00
>>>> Can you take a look into it and give me some feedback on it. 
>>>> Unfortunally I did not get the Jtreg test running under Windows 
>>>> (executing it as plain Java application at least does work)
>>>> Cheers
>>>> Patrick

More information about the 2d-dev mailing list