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

[Artem Ananiev]

On 10/2/2013 4:38 PM, Anthony Petrov wrote:
> On 10/02/2013 04:30 PM, Artem Ananiev wrote:
>>
>> On 10/2/2013 4:26 PM, Anthony Petrov wrote:
>>> On 10/02/2013 03:31 PM, sergey malenkov wrote:
>>>> This bug is about javadoc. What if I replace "the default toolkit" with
>>>> "the current window toolkit"?
>>>
>>> I'd be fine with such a change.
>>>
>>>
>>>> As I understand the Peer API is not public. So we can modify it without
>>>> thinking about backward compatibility.
>>>
>>> We can. But I don't think this is necessary for this fix at all.
>>
>> 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.

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