Note that this InvokeLater was added in 2003 by the omXXXXX as a fix for
JDK-4259272. It have some useful information.
On 07.04.2014 21:13, Petr Pchelko wrote:
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?
Unfortunately that’s not an option. They do not allow us to split the public
API packages, so the Clipboard must go into the data transfer 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.
I need some time to investigate this approach.. I’m not sure yet how would this
work. The issue with this approach is that we are creating a very fragile API..
If the desktop module is present the callbacks would go asynchronously on EDT,
if it’s not - synchronously. So imagine some third-patry component developed
not for the desktop, but using the datatransfer module and a Clipboard as a
simple holder for transferable. Then someone would reuse that component in the
application which also uses AWT. And the notifications would suddenly and
unpredictable transform to asynchronous. Nobody will ever understand what’s
happening..
With best regards. Petr.
07 апр. 2014 г., в 9:06 после полудня, Anthony Petrov
<[email protected]> написал(а):
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 <[email protected]> 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 <[email protected]> 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.
--
Best regards, Sergey.
