<AWT Dev> [8] Review request for 7081584: Specification for Window.isAlwaysOnTopSupported needs to be clarified

[Anthony Petrov]

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.

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
>>>>>>>
>>>>>