Hello.
I agree that it is a good time to make cleanup of all strange code that
we have. We will have enough time to catch regression.
On 04.10.2013 15:37, Anthony Petrov wrote:
On 10/04/2013 02:57 PM, Artem Ananiev wrote:
On 10/4/2013 2:45 PM, Anthony Petrov wrote:
On 10/02/2013 05:07 PM, Artem Ananiev wrote:
You're right, it's not necessary. However, since we touch this code
anyway, I'd be glad to have this redundant code removed.
It's not redundant. Please see my message below in the quote for
details.
Do you mean the following quote:
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).
? Extending the Component class and providing different implementation
for getToolkit() is the way to achieve this functionality. Without
this
extension, it doesn't matter if Component.getToolkit() calls to the
peer
or directly returns the default toolkit.
I can't say I fully agree with that. When using the default toolkit,
you
don't need to extend public AWT classes. I don't see why you would have
to do that when using a custom toolkit.
Sorry, I still don't get it... To me it looks like we don't change
anything. The current behavior is preserved, Component.getToolkit()
returns the default toolkit. Ability to extend the Component class and
change getToolkit() is not affected. All the weird cases like
co-existence of two different toolkits in the same process, or component
peers that are not created by the current toolkit, etc. are not worth
thinking about to me.
Could you provide a sample, which works with the current implementation
and won't work after the proposed fix, please?
No, unfortunately I don't have a working sample. I'm only considering
a theoretical possibility of several toolkits co-existing in a single
VM. I looked over the addNotify() implementation and see that it
relies upon the getToolkit() method. So indeed, w/o overriding it you
can't construct an AWT widget using a 3rd-party toolkit. OTOH, such a
toolkit might provide a factory method for components, and set its
peer field before returning the component instance to the app (w/o
actually extending the class). This case would break with the current
fix.
Also, w/o clear understanding of the reason why the
ComponentPeer.getToolkit() and the corresponding logic in
Component.getToolkit() were introduced in the first place, it looks
kind of scary to just drop this method so late in the JDK8 release cycle.
Since this part of the fix isn't mandatory for the specification
change, I still suggest to file a separate issue and investigate it
later because it doesn't seem urgent (as opposed to the spec change
itself.)
--
best regards,
Anthony
Thanks,
Artem
Can we file a separate P4 issue to evaluate this later, and only change
the specification with 7081584 ?
--
best regards,
Anthony
Thanks,
Artem
--
best regards,
Anthony
Thanks,
Artem
--
best regards,
Anthony
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
--
Best regards, Sergey.
