RFR: 8335231: [macos] Test java/awt/print/PrinterJob/Cancel/PrinterJobCancel.java failed on macOS because the case didn't get the expected PrintAbortException [v2]

[Phil Race]

On Tue, 30 Jul 2024 08:07:02 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> This comment was there from initial macosx port. Since RasterPrinterJob.`isCancelled` relies on `synchronized` block and since this `cancelCheck` method was called from native, it might have been suspected that it might block the native AppKit thread, so `invokeLater` was added.
>> But the problem was `LWCToolkit.invokeLater` is called with `null` argument,
>>  which was not a problem in initial macosx port but [JDK-8042087](https://bugs.openjdk.org/browse/JDK-8042087) got it modified in jdk9 to throw an exception if component argument is null, which is the case in `CPrinterJob.m#cancelCheck`
>> 
>>>  LWCToolkit.inokeAndWait is called on the Appkit thread, but if the component argument is null it uses EventQueue.invokeLater which would fail with an NPE in plugin mode. The method should be updated to throw an exception in case the provided component is null. 
>> 
>> Coming to your question, I guess if there is a deadlock, calling `cancelDoc` directly will also face the same issue as it also relies on same `synchronized(this)` block but I could not find any deadlock issue with the printing for which this `invokeLater` safeguard was added...
>> 
>> So, Is the above comment " fail with an NPE in plugin mode" still applicable i.e do we still support plugin mode?
>> If not, we can restore invokeLater call in this code and use `Toolkit.getToolkit` if the component is null as it was[ previously to JDK-8042087
>> ](https://github.com/openjdk/jdk/commit/bb2698cfa6f2bdc92c197f17a7d2f90003db05fa)
>
> I dont see any deadlock in my testing so I am using `isCancelled` .
> How do you normally "cancel" ongoing printing in macosx? I tried clicking on "x" in "Print Centre" when the specific print job is shown in the printer spooler and I dont see any deadlock for long printing tests like PrintAllFonts etc..

plugin mode is no longer a concern. 

So it seems to me that the worry is that some other thread holds the lock on the PrinterJob, and
is waiting for a print loop to return from native code running on the AppKit thread, which then up-calls to here and then needs to synchronize on the PrinterJob.
Other cases that I see aren't from native so aren't a problem.

"Coming to your question, I guess if there is a deadlock, calling cancelDoc directly will also face the same"

Yes whereas In the existing code it is run on the AppKit thread to avoid it ...
It seems safest to restore the invokeLater.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20027#discussion_r1698959433