Hello Dmitriy,
this version looks good to me.
Thanks,
Alexander.
On 04/04/2014 11:32 PM, Petr Pchelko wrote:
Hello, Dmitry.
This version looks great.
With best regards. Petr.
04 апр. 2014 г., в 8:16 после полудня, Dmitriy Ermashov
написал(а):
Hi,
Please, review the changeset for:
https
Hi, Sergey
Do you have any additions?
http://cr.openjdk.java.net/~yan/8038631/webrev.06/
--
Thanks,
Dima
On 04/07/2014 12:32 PM, Alexander Zvegintsev wrote:
Hello Dmitriy,
this version looks good to me.
Thanks,
Alexander.
On 04/04/2014 11:32 PM, Petr Pchelko wrote:
Hello, Dmitry.
This v
Hello, AWT Team.
Please review the fix for the javadoc typos:
https://bugs.openjdk.java.net/browse/JDK-669
The fix is here:
http://cr.openjdk.java.net/~pchelko/9/669/webrev.00/
With best regards. Petr.
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 on
Hello Petr,
the fix looks good to me.
Thanks,
Alexander.
On 04/07/2014 05:13 PM, Petr Pchelko wrote:
Hello, AWT Team.
Please review the fix for the javadoc typos:
https://bugs.openjdk.java.net/browse/JDK-669
The fix is here:
http://cr.openjdk.java.net/~pchelko/9/669/webrev.00/
With
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 Pchel
> 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 t
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
> 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 a
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8038113/webrev.02
- CachableJRSUIIcon explicitly implements Icon interface now
- getOptimizedImage() method is removed from the CachingScalingIcon
because NSImage always scales an image to the requested size
Hi, Petr.
The fix looks good
On 07.04.2014 17:13, Petr Pchelko wrote:
Hello, AWT Team.
Please review the fix for the javadoc typos:
https://bugs.openjdk.java.net/browse/JDK-669
The fix is here:
http://cr.openjdk.java.net/~pchelko/9/669/webrev.00/
With best regards. Petr.
--
Best reg
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
> 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
So we both see that replacing asynchronous behavior with a synchronous
one (or vice versa) could cause problems for existing or future apps.
This indicates that the issue is serious.
Note that the default implementation of the service could still dispatch
runnables asynchronously on a worker t
Note that this InvokeLater was added in 2003 by the omX 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
Hello.
Please review the fix for jdk 9.
In the fix Toolkit.sync() is implemented in the same way as on other
platforms. Note that on OSX we need additional step to flush the native
selectors queue, because all our rendering was done to offscreen texture.
Bug: https://bugs.openjdk.java.net/brow
Thanks Joe for pointing out the request should go to awt-dev.
Cheers,
Henry
On 04/07/2014 04:13 PM, Joe Darcy wrote:
Hi Henry,
Thanks for looking into this. FWIW, while I was working on
JDK-8039109: Fix unchecked and raw lint warnings in java.awt
I started looking at some sun.awt.*
17 matches
Mail list logo
