Looks fine.
Thanks,
Artem
On 10/2/2013 5:34 PM, sergey malenkov wrote:
http://cr.openjdk.java.net/~malenkov/7081584.8.1/
<http://cr.openjdk.java.net/%7Emalenkov/7081584.8.1/>
The specification is updated.
SAM
On 02.10.2013 16:29, Artem Ananiev wrote:
On 10/2/2013 3:31 PM, sergey malenkov wrote:
This bug is about javadoc. What if I replace "the default toolkit" with
"the current window toolkit"?
"The current window toolkit" sounds strange. It should be clarified or
replaced with "this window's toolkit" + {@see #getToolkit}.
Thanks,
Artem
As I understand the Peer API is not public. So we can modify it without
thinking about backward compatibility.
Thanks,
SAM
On 01.10.2013 21:47, Anthony Petrov wrote:
Hi Sergey,
I'm wondering what compatibility impact of this change is. The
specification for Component.getToolkit() suggests that in theory
several toolkits may co-exist in a single application. And thanks to
delegating to the ComponentPeer, the Component.getToolkit() could
return the actual toolkit for this component.
However, your fix effectively disallows a component to belong to any
toolkit other than the default one, because its getToolkit() will
never return anything else (unless you extend the component's class
and override the method).
I really don't know whether this is widely used, but I think this may
impact some applications.
Also, imagine a window is made to belong to another toolkit somehow,
even with your changes. Now, why should its ability to be
always-on-top depend on the default toolkit instead of the window's
own toolkit?
--
best regards,
Anthony
On 09/27/2013 08:49 PM, sergey malenkov wrote:
Hello,
Could you please review the following fix:
fix:http://cr.openjdk.java.net/~malenkov/7081584.8.0/
bug:https://bugs.openjdk.java.net/browse/JDK-7081584
The specification of the Window class waits for CCC approval. This fix
removes the getTookit method from the ComponentPeer class and its
subclasses.
Thanks,
SAM
