<AWT Dev> [9] Review Request: JDK-8039377 Clipboard should post notifications without using the EventQueue.invokeLater

[Anthony Petrov]

The synchronous vs. asynchronous calling of handlers is a big issue, 
IMO. Some applications may not be ready for that. I wouldn't change that 
part unless there's a bug in that functionality. And AFAIK, there's none.

As for other options, could you please provide more details on what 
exactly is required by the modularization project? Do they need to use 
the Clipboard class, or they actually only need a few other classes from 
the java.awt.datatransfer classes? In other words, can we keep the 
Clipboard class in the AWT module, and only move those other classes 
needed by RMI and friends to a separate module?

If that is not an option, then I'd go with a "service" for delayed 
execution approach. By default the service would provide synchronous 
dispatching of runnables, but AWT could override it with an 
implementation that calls invokeLater() under the hood.

--
best regards,
Anthony

On 4/7/2014 6:17 PM, Petr Pchelko wrote:
>> They could also get it using Clipboard.getSystemClipboard(), and the latter could call
>> the methods that you're changing from a non-EDT thread (directly or indirectly).
> This is not an issue since the system clipboard is always an instance of a SunClipboard
> which overrides these methods and uses SunToolkit.postEvent. And there's no API to
> change the class of the returned system clipboard.
>
>> A user could obtain an instance of a Clipboard object by using its public constructor.
> This is more interesting. If the user creates a Clipboard instance he has almost nothing to do with it.
> The only place where the custom Clipboard could be passed is TransferHandler.exportToClipboard.
> Indeed, after the change the Clipboard notifications will be called on the same thread where the
> exportToClipboard is called, but as TransferHandler is the swing API is must be called on EDT,
> so effectively nothing's changed. It might be an issue that the notifications become synchronous,
> but I didn't find any problems with it.
>
>>   In any case, the fix that you're proposing changes the threading contract for these methods considerably.
>> And I don't think that this change is safe.
>
> Option 2 is not safe as well, but it's way more complicated... Do you have any suggestions about some other
> options?
>
> Thank you.
> With best regards. Petr.
>
> On 07.04.2014, at 18:00, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>
>> I'm aware of the reasons behind this issue. However, I'm still unsure whether this is a safe enough solution. A user could obtain an instance of a Clipboard object by using its public constructor. They could also get it using Clipboard.getSystemClipboard(), and the latter could call the methods that you're changing from a non-EDT thread (directly or indirectly). In any case, the fix that you're proposing changes the threading contract for these methods considerably. And I don't think that this change is safe.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 4/7/2014 5:52 PM, Petr Pchelko wrote:
>>>> Clipboard is a part of AWT API. The AWT is a multi-threaded GUI toolkit, which means that users can call Clipboard's methods on
>>>> any thread. If we remove invokeLater(), we break this contract, which I'm not sure we want to do.
>>> The FlavorListener and ClipboardOwner interfaces do not state that the callbacks would be called on EDT, so at least we are not breaking the spec.
>>> The problem here is that Clipboard would be a  part of a different module and must be independent from AWT or the desktop module. Even reflectively independent.
>>> This means we have 2 options here: option 1 is implemented in the fix.
>>>
>>> Option 2 is to declare some "DelayedNotificationService", make the Clipboard look for this service using a ServiceLoader and make AWT implement the service
>>> using the invokeLater. So if the Clipboard would be used in absence of desktop module it would deliver the notifications in place, and with the desktop module it will
>>> use the invokeLater. Personally I think that the second option is way more fragile and unnecessary complicated.
>>>
>>> The only place where the Clipboard is used directly is in swing's sandbox clipboard, but it's used internally and only on EDT. And it does not leak to the user.
>>> So if we just remove the invokeLater we would likely not break anything. With the second option I would not be so sure.
>>>
>>> With best regards. Petr.
>>>
>>> On 07.04.2014, at 17:42, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>>
>>>> Hi Petr,
>>>>
>>>> Clipboard is a part of AWT API. The AWT is a multi-threaded GUI toolkit, which means that users can call Clipboard's methods on any thread. If we remove invokeLater(), we break this contract, which I'm not sure we want to do.
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 4/7/2014 5:16 PM, Petr Pchelko wrote:
>>>>> Hello, AWT Team.
>>>>>
>>>>> Please review the fix for the issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8039377
>>>>> The fix is here:
>>>>> http://cr.openjdk.java.net/~pchelko/9/8039377/webrev.00/
>>>>>
>>>>> The problem: Clipboard depend on the EventQueue. The solution - remove the invokeLater. The Clipboard object is used only as a Swing sandbox clipboard which is used from the EDT.
>>>>> The user can't use in as the System clipboard, so there's no worries about the callback being executed on some privileged thread. So we can simply remove the invokeLater here.
>>>>>
>>>>> With best regards. Petr.
>>>>>
>>>
>