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
